26단계커밋·푸시·되돌리기
커밋은 이름표, 푸시는 보내기입니다. 되돌려 본 사람이라야 큰일을 마음 놓고 맡깁니다.
걸리는 시간 · 읽기 약 5분 · 따라 하기 약 30분 · 난이도 ★★★ 심화 · 화면 확인 2026.09.27
이 단계를 마치면
- 커밋, 푸시, 되돌리기, 브랜치가 각각 무엇인지 말로 설명할 수 있습니다.
- 바뀐 것을 한 가지씩 나눠 우리말 메시지로 커밋하게 시킬 수 있습니다.
- 일부러 망가뜨린 커밋 하나만 되돌리고, 나머지가 살아 있는지 확인할 수 있습니다.
금요일 오후, 방금 올린 수정 때문에 팀원들 화면이 깨졌습니다. 어제로 돌아가는 버튼이 있다면 얼마나 좋을까요. 다행히 git에는 그 버튼이 있습니다.
25단계에서 이미 커밋과 푸시를 했습니다. "올려 줘"라고 했을 때 Claude가 한 일이 바로 그것입니다. 이제 그 일에 이름을 붙일 차례입니다. 돌아가는 모습을 먼저 보고 나서 배운 말은 경험에 단단히 달라붙습니다. 그리고 이 단계의 진짜 목표는 되돌리기입니다. 되돌릴 수 있다는 것을 몸으로 알아야 마음 놓고 큰일을 시킬 수 있습니다.
네 가지 말. git 명령도 함께 적어 두지만 외울 필요는 없습니다. 이름만 알아도 Claude의 보고를 읽을 수 있고, 무엇을 시켜야 할지 말할 수 있습니다. 실제 명령은 Claude Code에게 우리말로 시킵니다.
| 말 | 무엇인가 | Claude에게 하는 말 | 뒤에서 도는 명령 |
|---|---|---|---|
| 커밋 | 지금 상태에 이름표를 달아 기록해 둡니다 | "지금까지 한 것을 커밋해 줘" | git commit |
| 푸시 | 내 노트북의 기록을 GitHub로 보냅니다 | "푸시해 줘" | git push |
| 되돌리기 | 특정 커밋 하나가 한 일만 거꾸로 하는 새 기록을 쌓습니다 | "그 커밋만 되돌려 줘" | git revert |
| 브랜치 | 본줄 옆에 임시로 낸 길입니다 | "실험용 브랜치를 만들어서 해 줘" | git switch -c |
커밋과 푸시가 따로 있다는 점이 중요합니다. 커밋은 내 노트북 안에서 이름표를 다는 일이고, 푸시를 해야 비로소 GitHub로 갑니다. "커밋했습니다"라는 보고만 받고 GitHub를 열면 아무것도 바뀌지 않은 것처럼 보이는 까닭입니다. 보고를 읽을 때 두 말이 모두 들어 있는지 확인합시다.
한 커밋에 한 가지. 회사 소개, 화면 색, 연락처 수정을 한 덩어리로 커밋하면, 나중에 색만 되돌리고 싶을 때 나머지까지 함께 되돌아갑니다. 커밋 메시지는 사람이 읽는 글입니다. 무엇을 왜 바꿨는지 우리말로 적게 합니다. 몇 달 뒤의 내가, 혹은 이 도구를 이어받을 동료가 메시지만 보고도 무슨 일이었는지 알아볼 수 있어야 합니다.
| 나쁜 커밋 메시지 | 좋은 커밋 메시지 |
|---|---|
| 수정 | 연락처 전화번호를 대표번호로 바꿈 |
| update | 첫 화면 색을 회사 남색으로 통일 |
| 이것저것 고침 | (세 개로 나눕니다) 소개 문구 교체 / 색 통일 / 연락처 수정 |
되돌리기. 반드시 한 번은 직접 해 봅시다. 페이지 제목을 일부러 이상한 문장으로 바꾸고 커밋하고 푸시합니다. GitHub에 이상한 제목이 올라간 것을 확인합니다. 그런 다음 그 커밋만 되돌리게 합니다. 되돌리기는 기록을 지우지 않습니다. 이상한 제목을 넣은 일을 거꾸로 하는 새 기록이 하나 더 쌓일 뿐입니다. 그래서 커밋 목록에는 망가뜨린 기록과 되돌린 기록이 나란히 보입니다. 다른 커밋은 멀쩡히 살아 있어야 합니다. 이 경험을 해 본 사람과 안 해 본 사람은 다음부터 맡기는 일의 크기가 다릅니다.
되돌리는 방법 가운데는 기록 자체를 지우고 GitHub에 강제로 덮어쓰는 방법도 있습니다. 이 방법은 쓰지 않습니다. 다른 사람이 같은 저장소를 쓰고 있다면 그 사람의 기록까지 망가지고, 무엇이 있었는지 찾을 길도 사라집니다. Claude가 강제로 푸시하겠다며 허락을 구하면 거절하고 이유를 묻습니다. 23단계의 CLAUDE.md 예시에 "저장소 기록을 강제로 덮어쓰지 않는다"를 넣어 둔 이유가 이것입니다.
브랜치. 실험할 때 씁니다. 본줄은 배포되는 쪽입니다. 새 색 조합을 시험해 보고 싶은데 본줄에서 바로 고치면, 마음에 들지 않아도 팀원 화면은 이미 바뀌어 있습니다. 브랜치를 하나 내서 거기서 고치고, 마음에 들면 본줄에 합치고, 아니면 버리면 됩니다. 다만 브랜치를 쓰기 시작하면 흔히 겪는 사고가 하나 있습니다. 고쳐서 푸시했는데 배포된 화면이 그대로인 경우입니다. 배포 서비스는 대개 본줄만 주소에 연결합니다. 다른 브랜치에 올린 것은 본줄에 합치기 전까지 그 주소에 반영되지 않습니다. 28단계에서 다시 다룹니다.
헷갈릴 때 꺼내 볼 표를 정리해 둡니다.
| 상황 | 할 일 |
|---|---|
| 한 가지 일을 끝냈습니다 | 커밋합니다. 메시지는 우리말로 |
| 팀원이 봐야 합니다 | 푸시합니다 |
| 방금 올린 것 하나가 틀렸습니다 | 그 커밋만 되돌립니다 |
| 해 볼지 말지 모르는 실험입니다 | 브랜치에서 합니다 |
| Claude가 기록을 지우거나 강제로 덮어쓰려 합니다 | 거절하고 이유를 묻습니다 |
Codex에서는 공식 안내도 작업 전후로 커밋해 두고 되돌리라고 권합니다. 이 단계에서 익힌 커밋 습관이 Codex에서는 되돌리기의 중심이 됩니다. 데스크톱 앱의 리뷰 화면에서는 파일이나 덩어리 단위로 되돌릴 수도 있습니다. 브랜치와 비슷하게 작업마다 따로 떼어 돌리는 Worktree는 35단계에서 다룹니다.
현장 장면
저장 기능을 붙인 날, 윤 과장은 퇴근 직전에 "오늘 한 것 올려 줘"라고 했습니다. 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에 갑니다.
- 되돌리기는 기록을 지우지 않고 새로 쌓습니다. 강제로 덮어쓰기는 거절합니다.