29단계커밋·푸시·되돌리기
커밋은 이름표, 푸시는 보내기다. 되돌려 본 사람이라야 큰일을 마음 놓고 맡긴다.
걸리는 시간 · 읽기 약 5분 · 따라 하기 약 30분 · 난이도 ★★★ 심화 · 화면 확인 2026.09.27
이 단계를 마치면
- 커밋, 푸시, 되돌리기, 브랜치가 각각 무엇인지 말로 설명할 수 있다.
- 바뀐 것을 한 가지씩 나눠 우리말 메시지로 커밋하게 시킬 수 있다.
- 일부러 망가뜨린 커밋 하나만 되돌리고, 나머지가 살아 있는지 확인할 수 있다.
금요일 오후, 방금 올린 수정 때문에 팀원들 화면이 깨졌다. 어제로 돌아가는 버튼이 있다면 얼마나 좋을까. 다행히 git에는 그 버튼이 있다.
28단계에서 이미 커밋과 푸시를 했다. "올려 줘"라고 했을 때 Claude가 한 일이 바로 그것이다. 이제 그 일에 이름을 붙일 차례다. 돌아가는 모습을 먼저 보고 나서 배운 말은 경험에 단단히 달라붙는다. 그리고 이 단계의 진짜 목표는 되돌리기다. 되돌릴 수 있다는 것을 몸으로 알아야 마음 놓고 큰일을 시킬 수 있다.
네 가지 말. git 명령도 함께 적어 두지만 외울 필요는 없다. 이름만 알아도 Claude의 보고를 읽을 수 있고, 무엇을 시켜야 할지 말할 수 있다. 실제 명령은 Claude Code에게 우리말로 시킨다.
| 말 | 무엇인가 | Claude에게 하는 말 | 뒤에서 도는 명령 |
|---|---|---|---|
| 커밋 | 지금 상태에 이름표를 달아 기록해 둔다 | "지금까지 한 것을 커밋해 줘" | git commit |
| 푸시 | 내 노트북의 기록을 GitHub로 보낸다 | "푸시해 줘" | git push |
| 되돌리기 | 특정 커밋 하나가 한 일만 거꾸로 하는 새 기록을 쌓는다 | "그 커밋만 되돌려 줘" | git revert |
| 브랜치 | 본줄 옆에 임시로 낸 길이다 | "실험용 브랜치를 만들어서 해 줘" | git switch -c |
커밋과 푸시가 따로 있다는 점이 중요하다. 커밋은 내 노트북 안에서 이름표를 다는 일이고, 푸시를 해야 비로소 GitHub로 간다. "커밋했습니다"라는 보고만 받고 GitHub를 열면 아무것도 바뀌지 않은 것처럼 보이는 까닭이다. 보고를 읽을 때 두 말이 모두 들어 있는지 확인하자.
한 커밋에 한 가지. 회사 소개, 화면 색, 연락처 수정을 한 덩어리로 커밋하면, 나중에 색만 되돌리고 싶을 때 나머지까지 함께 되돌아간다. 커밋 메시지는 사람이 읽는 글이다. 무엇을 왜 바꿨는지 우리말로 적게 한다. 몇 달 뒤의 내가, 혹은 이 도구를 이어받을 동료가 메시지만 보고도 무슨 일이었는지 알아볼 수 있어야 한다.
| 나쁜 커밋 메시지 | 좋은 커밋 메시지 |
|---|---|
| 수정 | 연락처 전화번호를 대표번호로 바꿈 |
| update | 첫 화면 색을 회사 남색으로 통일 |
| 이것저것 고침 | (세 개로 나눈다) 소개 문구 교체 / 색 통일 / 연락처 수정 |
되돌리기. 반드시 한 번은 직접 해 보자. 페이지 제목을 일부러 이상한 문장으로 바꾸고 커밋하고 푸시한다. GitHub에 이상한 제목이 올라간 것을 확인한다. 그런 다음 그 커밋만 되돌리게 한다. 되돌리기는 기록을 지우지 않는다. 이상한 제목을 넣은 일을 거꾸로 하는 새 기록이 하나 더 쌓일 뿐이다. 그래서 커밋 목록에는 망가뜨린 기록과 되돌린 기록이 나란히 보인다. 다른 커밋은 멀쩡히 살아 있어야 한다. 이 경험을 해 본 사람과 안 해 본 사람은 다음부터 맡기는 일의 크기가 다르다.
되돌리는 방법 가운데는 기록 자체를 지우고 GitHub에 강제로 덮어쓰는 방법도 있다. 이 방법은 쓰지 않는다. 다른 사람이 같은 저장소를 쓰고 있다면 그 사람의 기록까지 망가지고, 무엇이 있었는지 찾을 길도 사라진다. Claude가 강제로 푸시하겠다며 허락을 구하면 거절하고 이유를 묻는다. 26단계의 CLAUDE.md 예시에 "저장소 기록을 강제로 덮어쓰지 않는다"를 넣어 둔 이유가 이것이다.
브랜치. 실험할 때 쓴다. 본줄은 배포되는 쪽이다. 새 색 조합을 시험해 보고 싶은데 본줄에서 바로 고치면, 마음에 들지 않아도 팀원 화면은 이미 바뀌어 있다. 브랜치를 하나 내서 거기서 고치고, 마음에 들면 본줄에 합치고, 아니면 버리면 된다. 다만 브랜치를 쓰기 시작하면 흔히 겪는 사고가 하나 있다. 고쳐서 푸시했는데 배포된 화면이 그대로인 경우다. 배포 서비스는 대개 본줄만 주소에 연결한다. 다른 브랜치에 올린 것은 본줄에 합치기 전까지 그 주소에 반영되지 않는다. 31단계에서 다시 다룬다.
헷갈릴 때 꺼내 볼 표를 정리해 둔다.
| 상황 | 할 일 |
|---|---|
| 한 가지 일을 끝냈다 | 커밋한다. 메시지는 우리말로 |
| 팀원이 봐야 한다 | 푸시한다 |
| 방금 올린 것 하나가 틀렸다 | 그 커밋만 되돌린다 |
| 해 볼지 말지 모르는 실험이다 | 브랜치에서 한다 |
| Claude가 기록을 지우거나 강제로 덮어쓰려 한다 | 거절하고 이유를 묻는다 |
현장 장면
저장 기능을 붙인 날, 윤 과장은 퇴근 직전에 "오늘 한 것 올려 줘"라고 했다. GitHub의 커밋 목록에 "Update index.html"이라는 기록이 하나 생겼다. 그 안에는 저장 기능, 입력 항목 순서 변경, 색 변경이 한데 뒤섞여 있었다. 다음 날 아침 팀장이 말했다. "색이 너무 어두운데?" 색만 되돌리면 되겠다고 생각한 순간, 윤 과장은 문제를 깨달았다. 되돌리면 저장 기능까지 함께 사라진다.
윤 과장은 CLAUDE.md에 "커밋은 한 가지 일씩, 메시지는 우리말 한 문장으로"를 적었다. 그리고 연습 삼아 일부러 사고를 쳤다. 페이지 제목을 "테스트 제목입니다 지우지 마세요"로 바꿔 커밋하고 푸시했다. GitHub에서 그 제목이 보이는 것을 확인한 뒤, 그 커밋만 되돌려 달라고 했다. Claude는 커밋 목록을 보여 주고 되돌리는 계획을 설명한 뒤, 푸시하기 전에 한 번 더 물었다. 푸시하자 커밋 목록에 "되돌림: 테스트 제목" 기록이 새로 쌓였다. 제목은 원래대로 돌아왔고, 저장 기능은 멀쩡했다.
진짜 위기는 그다음에 왔다. 색 실험을 하던 중에 윤 과장이 GitHub 화면에서 오타 하나를 직접 고쳤다. 그 뒤 노트북에서 푸시하자 거절당했다. Claude는 원격 기록을 강제로 덮어쓰면 해결된다고 제안했다. 가장 빠른 길이었지만 윤 과장은 거절했다. 대신 GitHub에서 고친 오타가 사라지지 않도록 받아와 합치는 방법을 요청했다. 그 뒤로 색 실험은 브랜치에서 했다. 마음에 드는 색이 나오자 본줄에 합쳤고, 이번에는 "첫 화면 색을 밝은 남색으로 바꿈"이라는 커밋 하나가 따로 기록됐다.
따라 하기
- 소개 문구, 화면 색, 연락처처럼 서로 다른 세 곳을 고치고, 아래 첫 번째 프롬프트로 세 개로 나눠 커밋하게 한 뒤 푸시한다. 성공 기준: GitHub 커밋 목록에 우리말 메시지 세 개가 따로 보인다.
- 페이지 제목을 일부러 이상한 문장으로 바꿔 커밋하고 푸시한다. 성공 기준: GitHub 화면의 파일에 이상한 제목이 보인다.
- 아래 두 번째 프롬프트로 그 커밋만 되돌리게 한다. 성공 기준: 커밋 목록에 되돌린 기록이 새로 생기고, 제목이 원래대로 돌아온다.
- 앞의 세 변경이 살아 있는지 확인한다. 성공 기준: 문구, 색, 연락처가 모두 고친 그대로다.
- 실험용 브랜치를 만들어 색 하나를 바꿔 보고, 본줄에 합칠지 버릴지 정해 그대로 시킨다. 성공 기준: 합쳤다면 본줄에 반영돼 있고, 버렸다면 본줄은 그대로다.
복사해 쓰는 프롬프트
지금까지 바뀐 파일을 보여 주고, 서로 다른 일끼리 나눠서 커밋해 줘.
한 커밋에는 한 가지 일만 담고, 메시지는 무엇을 왜 바꿨는지 우리말 한 문장으로 적어 줘.
나누는 계획을 먼저 보여 주고, 내가 좋다고 하면 커밋한 뒤 푸시해 줘.
최근 커밋 목록을 보여 주고, 각 커밋이 무엇을 바꿨는지 우리말로 짧게 설명해 줘.
그중 [되돌릴 커밋 설명] 커밋 하나만 되돌려 줘. 다른 커밋의 변경은 그대로 둬.
기록을 지우거나 강제로 덮어쓰는 방법은 쓰지 마.
되돌린 뒤에는 무엇이 바뀌었는지 보여 주고, 푸시하기 전에 나에게 먼저 물어봐.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| 커밋했다는데 GitHub에 안 보인다 | 커밋만 하고 푸시를 안 했다 | "푸시해 줘"라고 하고 GitHub를 새로고침한다 |
| Updates were rejected, non-fast-forward | GitHub 화면에서 직접 고쳐 양쪽 기록이 달라졌다 | 받아와 합치게 한다. 강제로 덮어쓰지 않는다 |
| conflict, 충돌 | 같은 줄을 양쪽에서 다르게 고쳤다 | 양쪽 내용을 나란히 보여 달라고 하고, 남길 쪽을 내가 정한다 |
| nothing to commit | 바뀐 것이 없거나 이미 커밋했다 | 파일이 저장됐는지, 커밋 목록에 이미 있는지 확인하게 한다 |
실습 파일
공개 저장소에 올려 둔 가공 자료와 양식이다. 회사 자료 대신 먼저 이것으로 해 본다.
- 샘플 자료 영업_방문기록.csv · 영업 사원 네 명의 3월 방문 기록 30건
스스로 점검
- ☐ 커밋과 푸시의 차이를 옆 사람에게 한 문장으로 말할 수 있는가
- ☐ 커밋 목록에 되돌린 기록이 하나 이상 있는가
- ☐ 강제로 덮어쓰자는 제안을 거절할 이유를 말할 수 있는가
점검 해설 보기
- "커밋은 내 노트북에서 이름표를 다는 일이고, 푸시해야 GitHub로 간다"는 식으로 말할 수 있으면 통과다. 커밋했다는데 GitHub에 안 보인 경험이 있다면 바로 이 차이 때문이다. 「네 가지 말」 표를 다시 읽는다.
- GitHub 커밋 목록에 일부러 망가뜨린 커밋과 그것을 되돌린 기록이 나란히 있고, 다른 변경은 그대로 살아 있으면 통과다. 아직이라면 「따라 하기」 2~4번대로 제목을 이상하게 바꿔 올린 뒤 두 번째 프롬프트로 그 커밋만 되돌리게 한다.
- 강제로 덮어쓰면 다른 사람의 기록까지 망가지고 무엇이 있었는지 찾을 길이 사라진다고 설명할 수 있으면 통과다. 막연하다면 「되돌리기」 부분과 윤 과장이 강제 푸시 대신 받아와 합치기를 고른 「현장 장면」을 다시 읽는다.
기억할 것
- 한 커밋에 한 가지만, 메시지는 사람 말로. 커밋 다음에 푸시까지 해야 GitHub에 간다.
- 되돌리기는 기록을 지우지 않고 새로 쌓는다. 강제로 덮어쓰기는 거절한다.