한 줄 요약
“실수해도 되돌릴 수 있다”는 걸 말로만 듣지 않고, 직접 사이트를 망가뜨렸다가 되돌리는 걸 로컬에서부터 실제 배포된 사이트까지 끝까지 해봤다.
이런 분께 도움이 될 것 같아요: 커밋·되돌리기가 뭔지 몰라서 “코드 잘못 건드리면 어떡하지” 걱정되는 분. 이미 사이트를 배포했고, “고치다가 망가뜨리면 어떻게 되돌리지?”가 궁금한 분.
Before — 커밋이 뭔지도 몰랐다
어제(7/27) GitHub·Vercel로 사이트를 배포하긴 했는데, 정작 “커밋”이라는 말 자체를 몰랐다. 그리고 이런 게 궁금했다.
- 지금까지 한 작업(학습메이트·로드맵·랜딩·배포)이 다 안전하게 저장돼 있는 게 맞나?
- 사이트를 고치다가 잘못 망가뜨리면, 원래대로 되돌릴 수 있나?
- 되돌리는 게 로컬에서만 되는 건지, 실제 배포된 사이트에도 되는 건지?
어떻게 — 실제 쓴 프롬프트 그대로
1. 커밋이 뭔지부터 쉽게 물어보기
방금까지 작업한 걸 커밋으로 저장해줘. 나는 코딩을 몰라, 커밋이 뭔지
한 줄로 쉽게 설명하면서 해줘. 그리고 "뭘 저장했는지" 알아보기 쉬운
이름(메시지)도 네가 붙여줘.
→ “커밋 = 지금 이 순간을 저장 지점(세이브포인트)으로 찍어두는 것”이라는 비유로 설명 듣고, 저장까지 한 번에 끝났다. 커밋 메시지(“GitHub·Vercel 배포 사례 정리…”)도 알아서 붙여줬다.
2. 지금까지 한 작업이 다 저장됐는지 확인하기
학습메이트, 로드맵, 랜딩, 배포까지 저장한거야?
→ 첫날 만든 것들(학습메이트·로드맵·랜딩)은 이미 첫 번째 커밋에, 오늘 한 배포 작업은 방금 커밋에 나뉘어 다 들어있다는 걸 확인받았다. “두 번의 세이브포인트로 다 저장돼 있다”는 답을 들으니 안심이 됐다.
3. 일부러 망가뜨려달라고 부탁하기 (되돌리기 연습 1탄)
내 랜딩 소개글 첫 문장을 아무렇게나 바꿔서 살짝 망가뜨려줘.
바뀐 걸 로컬로 보여줘. (이건 되돌리기 연습이야, 걱정 마)
→ 랜딩페이지 첫 문장이 “바나나마케팅을 했었고 우주로 잠시 쉬는 동안 삼겹살자격증 새로 땄어요asdf”로 바뀐 걸 로컬 화면(localhost)에서 확인. 그런데 화면 맨 위 큰 제목(헤드라인)은 안 바뀌어 있어서 “랜딩페이지에는 안 바뀐 것 같은데?”라고 물었더니, 헤드라인도 같이 망가뜨려줬다.
4. 로컬과 실제 배포 사이트가 다르다는 걸 직접 확인
배포된 실제 주소(my-learning-hub-omega.vercel.app)로 들어가보니 그대로였다. “여기는 왜 안 바뀌었어?”라고 물었더니, 커밋만 하고 GitHub에 올리지(push) 않았기 때문이라는 답을 들었다. 로컬 파일 수정과 실제 배포 사이트는 별개라는 걸 이때 처음 알았다.
5. 되돌리기 (git restore)
방금 바꾼 걸 취소하고, 마지막으로 커밋한 상태로 되돌려줘.
그리고 원래대로 돌아왔는지 로컬로 보여줘.
→ 아직 커밋 전이었던 변경사항이라 git restore로 깔끔하게 원래 문장으로 돌아왔다.
6. 한 단계 더 — 실제 배포 사이트까지 망가뜨렸다 되돌리기 (2탄)
여기서 궁금해졌다. “로컬 되돌리기는 해봤는데, 그럼 실제 배포된 사이트를 망가뜨렸다가 되돌리는 것도 되나?”
추가 작업해보고싶어. 배포사이트까지 다시 바꿔보고싶은데 내 랜딩 소개글
첫 문장을 아무렇게나 바꿔서 살짝 망가뜨려줘. 바뀐 걸 로컬로 보여줘.
그리고 배포사이트까지 바꿔줘
→ 이번엔 로컬에서 확인 후, 커밋 + GitHub push까지 진행. 1~2분 기다리니 실제 배포 사이트에도 망가진 문장(“떡볶이마케팅을 했었고, 달나라로 잠시 쉬는 동안 라면요리사 자격증을 새로 땄어요zzz”)이 그대로 떴다.
7. 이미 올라간 것도 되돌릴 수 있는지 (git revert)
방금 바꾼 걸 취소하고, 마지막으로 커밋한 상태로 되돌려줘.
그리고 원래대로 돌아왔는지 로컬로 보여줘. 사이트에도 반영해줘
→ 이번엔 이미 push까지 된 상태라 git restore가 아니라 git revert(이 커밋을 취소하는 새 커밋을 하나 더 쌓는 방식)를 썼다. 로컬 확인 → 다시 push → 1~2분 뒤 실제 배포 사이트도 원래 문장으로 돌아온 걸 확인했다.
막힘 → 해결
막힘 1 — 랜딩페이지를 망가뜨렸는데 화면에 안 보였다. → 알고 보니 헤드라인(제목)과 소개 본문이 따로 있는 구조였는데, 본문만 바뀌고 헤드라인은 그대로라 “안 바뀐 것 같다”고 느낀 거였다. 둘 다 바꿔달라고 하니 해결.
막힘 2 — 로컬은 바뀌었는데 실제 사이트는 그대로였다. → “커밋 = 저장”과 “push = 실제 사이트에 반영”이 다른 단계라는 걸 이때 알았다. 커밋만으로는 내 컴퓨터 안에서만 저장된 거고, GitHub에 push해야 Vercel이 그걸 보고 재배포한다.
막힘 3 — 이미 push한 걸 되돌릴 땐 아까랑 같은 방법이 안 통할 것 같았다.
→ 아직 커밋 전이면 git restore, 이미 커밋+push까지 됐으면 git revert(취소하는 새 커밋을 쌓기)를 쓴다는 걸 배웠다. 파일을 강제로 되돌리는 게 아니라 “이걸 취소했다”는 기록이 남는 방식이라 더 안전하다고 했다.
After — 결과
- 로컬 되돌리기(
git restore)와 배포 사이트까지 반영된 되돌리기(git revert+ push) 둘 다 직접 해봄 - “커밋 → push → 재배포”라는 3단계 흐름을 몸으로 확인
- 이제는 “잘못 건드려도 되돌릴 수 있다”는 걸 알아서, 사이트를 고치는 게 덜 무섭다
오늘 기분
되돌리기가 무섭지 않다는 걸 알게 돼서 좋았다. 일부러 사이트를 망가뜨려보고 다시 살리는 연습을 로컬뿐 아니라 실제 배포 사이트까지 해보니, “잘못돼도 되돌릴 수 있다”는 게 실감 나서 마음이 편해졌다.
재사용 자산 — 되돌리기 부탁할 때 그대로 쓸 프롬프트
| 상황 | 그대로 쓸 프롬프트 |
|---|---|
| 지금까지 작업이 저장됐는지 확인할 때 | ”지금까지 한 작업 다 저장(커밋)된 거 맞아? 확인해줘.” |
| 아직 커밋 안 한 변경을 취소하고 싶을 때 | ”방금 바꾼 거 취소하고 마지막으로 저장한 상태로 되돌려줘.” |
| 이미 커밋(+push)까지 된 걸 취소하고 싶을 때 | ”방금 그 커밋 취소해줘. 실제 사이트에도 반영해줘.” |
| 로컬만 바뀌었는지, 실제 사이트도 바뀌었는지 헷갈릴 때 | ”이거 로컬에서만 바뀐 거야, 아니면 실제 사이트에도 반영된 거야?” |