깃(git) commit 사용법, 메시지 고치기와 취소·되돌리기까지

git commit으로 새 커밋을 만드는 것과 이미 만든 커밋을 고치거나 취소하는 것은 로그에 남는 모습이 다릅니다. 메시지를 고친 커밋은 해시가 바뀌어 예전 커밋이 로그에서 사라지고, 되돌린 커밋은 로그에 그대로 남습니다. 새 폴더 하나에서 git commit 관련 명령 일곱 단계를 차례로 실행한 이번 로컬 실행에서는 앞의 일곱 단계가 모두 종료 코드 0으로 끝났고, 소요 시간은 각각 0.0초로 기록됐습니다. Claude Code에게 커밋 메시지를 쓰게 한 마지막 단계는 이번 실행에서 5.2초로 기록됐습니다.

따라 할 순서 한눈에 보기

AI 에이전트가 파일을 고친 뒤 바로 커밋했다가 메시지나 파일을 다시 손봐야 할 때 쓸 수 있는 순서입니다. 아래 번호대로 따라 해 보세요.

1. 깃 버전 확인
2. 새 저장소를 만들고 첫 커밋
3. 제목과 본문을 나눈 메시지로 커밋
4. 방금 한 커밋의 메시지만 고치기(--amend)
5. 빠뜨린 파일을 넣어 같은 커밋 다시 만들기(--amend --no-edit)
6. 커밋은 취소하고 변경은 스테이지에 남기기(reset --soft)
7. 다시 커밋한 뒤 새 커밋으로 되돌리기(revert)
8. 스테이지에 올린 변경을 Claude Code에게 보여 주고, 받은 메시지로 커밋

4~6번은 이미 있는 기록을 고쳐 쓰고, 7번은 기록을 하나 더 붙입니다. 이 차이는 원격에 올린 뒤에 특히 중요해지는데, 단계별로 출력을 보면서 확인해 보죠.

도식출처: 직접 실행한 순서

함께 읽을 글

• 깃(Git) 사용법, 처음 쓰는 명령을 순서대로 직접 해 보니
• 파이썬(Python) 딕셔너리 사용법, 자주 쓰는 동작을 직접 실행해 보니
• 깃(Git) pull 사용법, 받아오기부터 충돌 해결까지 직접 해 보니

첫 커밋은 어떻게 만들까요?

먼저 버전을 확인합니다. 이 글의 출력은 모두 아래 버전에서 나왔습니다.

$ git --version
git version 2.54.0

이어서 새 저장소를 만들고 첫 커밋을 남깁니다. 작성자 이름과 메일은 --global 없이 정해서 이 저장소에만 적용되게 했어요.

$ git init -q -b main && git config user.name "Finn" && git config user.email "lab@solodevnote.com" && printf '# 메모\n' > README.md && git add README.md && git commit -m "첫 커밋"
[main (최상위-커밋) fbecc40] 첫 커밋
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

git commit은 스테이지(index)에 올린 내용으로 새 커밋을 만듭니다. 그래서 이 글처럼 옵션이나 파일 경로 없이 커밋할 때는 수정한 파일도 먼저 git add로 스테이지에 올립니다. git-commit 설명서에는 다른 방법도 적혀 있는데, 예를 들어 -a를 붙이면 이미 추적 중인 파일의 수정과 삭제를 자동으로 반영해 커밋합니다. 출력의 '최상위-커밋'은 이 저장소의 첫 커밋을 뜻합니다.

제목과 본문은 어떻게 나눠 쓸까요?

에이전트가 한 일을 나중에 다시 찾으려면 제목 한 줄에 본문 설명을 붙여 두는 게 좋습니다. 설명서에 따르면 -m을 여러 번 주면 각 값이 별도 문단으로 이어집니다.

$ printf '할 일 1\n' > todo.txt && git add todo.txt && git commit -q -m "할 일 목록 추가" -m "오늘 할 일을 todo.txt에 적었다." && git log -1
commit ccb59863e09ee0075d17f99a4a791f6ac9f4ac03
Author: Finn <lab@solodevnote.com>
Date:   Mon Oct 26 04:36:47 2026 +0900

    할 일 목록 추가

    오늘 할 일을 todo.txt에 적었다.

첫 -m은 제목, 두 번째 -m은 한 줄 띄운 본문이 되었습니다. 이렇게 만든 커밋의 메시지가 마음에 들지 않으면 어떻게 할까요?

방금 한 커밋 메시지 고치는 방법

바로 직전 커밋이라면 --amend에 새 메시지를 주면 됩니다.

$ git commit -q --amend -m "할 일 목록 파일 추가" && git log --oneline
a57ef16 할 일 목록 파일 추가
fbecc40 첫 커밋

로그에 남은 건 새 해시 a57ef16뿐이고, 앞 단계의 커밋은 보이지 않습니다. 설명서는 --amend가 현재 브랜치의 맨 끝 커밋을 새 커밋으로 바꾼다고 설명합니다. Git 공식 책 한국어판 되돌리기도 이전 커밋은 일어나지 않은 일이 되고 히스토리에 남지 않는다고 적고 있죠. 커밋 뒤에 아무것도 고치지 않았다면 바뀌는 건 메시지뿐입니다.

빠뜨린 파일을 같은 커밋에 넣는 방법

예를 들어 에이전트가 만든 파일 하나를 스테이지에 올리지 않고 커밋했다면, 그 파일을 추가한 뒤 --amend --no-edit를 씁니다. --no-edit는 메시지를 바꾸지 않고 편집기도 열지 않는다는 뜻이에요.

$ printf '메모 1\n' > notes.txt && git add notes.txt && git commit -q --amend --no-edit && git show --stat --oneline HEAD
a2bcc5b 할 일 목록 파일 추가
 notes.txt | 1 +
 todo.txt  | 1 +
 2 files changed, 2 insertions(+)

메시지는 그대로인데 해시가 a2bcc5b로 또 바뀌었고, 커밋 하나에 두 파일이 함께 들어갔습니다. 공식 책은 이 방식의 장점을 "앗차, 빠진 파일 넣었음" 같은 커밋을 따로 만들지 않는 데서 찾습니다.

깃 커밋 취소, 변경은 남기려면?

커밋 자체를 없던 일로 하되 작업한 내용은 살려 두고 싶다면 git reset --soft HEAD~1을 실행해 보세요.

$ git reset --soft HEAD~1 && git status --short && git log --oneline
A  notes.txt
A  todo.txt
fbecc40 첫 커밋

로그는 첫 커밋으로 돌아갔고, 두 파일은 A 표시로 스테이지에 그대로 남았습니다. 그래서 바로 다시 커밋할 수 있죠. 설명서도 커밋 직후 실수를 발견하면 git reset으로 복구할 수 있다고 합니다. 다만 공식 책은 git reset이 위험한 명령이고 --hard와 함께 쓰면 더 위험하다고 경고합니다. 이번 실행에서는 --soft만 썼어요.

이미 한 커밋을 새 커밋으로 되돌리기

그럼 기록을 지우지 않고 변경만 거꾸로 돌리고 싶을 땐 어떻게 할까요? 이럴 때는 git revert를 씁니다. 아래는 스테이지에 남은 두 파일을 다시 커밋한 뒤 바로 되돌린 기록입니다.

$ git commit -q -m "할 일과 메모 추가" && git revert --no-edit HEAD && git log --oneline && ls
[main a25fbb1] Revert "할 일과 메모 추가"
 Date: Mon Oct 26 04:36:47 2026 +0900
 2 files changed, 2 deletions(-)
 delete mode 100644 notes.txt
 delete mode 100644 todo.txt
a25fbb1 Revert "할 일과 메모 추가"
d80fff1 할 일과 메모 추가
fbecc40 첫 커밋
README.md

두 파일을 지우는 Revert 커밋이 새로 생겼고, 폴더에는 README.md만 남았습니다. 앞 단계들과 다른 점은 원래 커밋 d80fff1이 로그에 그대로 있다는 거예요. 네 명령이 로그와 파일을 어떻게 바꿨는지 표로 나란히 보면 차이가 더 분명해집니다.

도식출처: 근거를 바탕으로 코드가 그린 도식

원격에 올린 커밋을 고칠 때 조심할 점

설명서는 이미 공개한 커밋을 --amend로 고친다면 히스토리를 다시 쓰는 일의 의미를 이해해야 한다고 당부합니다. 자세한 내용은 git-rebase 설명서의 업스트림 리베이스 복구 절로 안내하죠. 혼자 개발하더라도 다른 컴퓨터나 배포 서버가 그 커밋을 받아 갔다면 해당하는 이야기입니다.

그래서 판단 기준을 하나 두면 편합니다. 원격에 올리기 전이라면 --amend나 reset --soft로 정리하고, 올린 뒤라면 고쳐 쓰는 명령을 쓰기 전에 설명서의 해당 절부터 확인하는 편이 안전합니다. 이번 실행은 원격 없이 로컬에서만 했기 때문에 푸시 이후 동작은 확인하지 않았어요.

실수로 고쳐 썼다면 아직 기회는 있습니다. 공식 책에 따르면 --amend로 다시 커밋한 것도 복구할 수 있지만, 커밋하지 않고 잃어버린 것은 되돌릴 수 없습니다.

클로드 코드에게 커밋 메시지 맡기기

마지막으로 스테이지에 올린 변경(git diff --staged)을 Claude Code에 넘겨 제목 한 줄을 받고, 그 메시지로 바로 커밋했습니다. Claude Code는 미리 로그인된 상태였고 모델은 --model opus로 정했어요.

$ printf '# 메모\n\n이 저장소는 git commit 연습용이다.\n' > README.md && git add README.md && msg=$(git diff --staged | claude --model opus -p "이 변경을 설명하는 한국어 커밋 메시지 제목 한 줄만 출력해. 따옴표나 설명은 붙이지 마.") && echo "AI가 쓴 메시지: $msg" && git commit -q -m "$msg" && git log --oneline -1
AI가 쓴 메시지: README에 저장소 설명 추가
2c0896a README에 저장소 설명 추가

이 단계는 5.2초 걸렸고, 받은 메시지는 "README에 저장소 설명 추가"였습니다. 같은 명령이라도 실행할 때마다 다른 메시지가 나올 수 있다는 점을 기억해 두세요. 위 명령은 메시지를 보여 준 다음 곧바로 커밋까지 합니다. 메시지를 먼저 읽고 싶다면 echo까지만 실행하고 커밋은 따로 하는 방법도 있어요. 혹시 마음에 들지 않게 커밋됐더라도 4단계의 --amend로 바로 고칠 수 있습니다.

도식출처: 근거를 바탕으로 코드가 그린 도식

자주 하는 실수와 마지막 점검

공식 문서가 짚는 실수는 이렇습니다.

• 수정한 파일을 git add 없이 커밋하기: 수정한 파일도 스테이지에 올려야 커밋에 들어갑니다. -a는 수정·삭제한 파일만 올리고, 깃이 모르는 새 파일은 올리지 않아요.
• git reset에 --hard 붙이기: 공식 책이 특히 위험하다고 경고하는 조합입니다.
• git checkout -- <file>로 되돌리기: 원래 파일로 덮어쓰기 때문에 수정한 내용이 모두 사라집니다.
• 고쳐 쓴 커밋이 로그에 없다고 당황하기: --amend는 새 커밋으로 바꾸는 것이라 예전 해시가 보이지 않는 게 정상입니다.

커밋하기 전에는 아래 항목을 확인해 보세요.

• git status --short로 스테이지에 올라간 파일이 맞는지
• AI가 쓴 메시지가 실제 변경과 맞는지
• 고칠 커밋이 이미 원격에 올라갔는지
• 고친 뒤 git log --oneline으로 기록이 원하는 모양인지

측정 조건과 한계

깃 단계의 0.0초는 한 번 잰 값이라 명령끼리 속도를 비교하는 근거로 쓰기는 어렵습니다. Claude Code의 5.2초와 메시지 내용도 한 번 실행한 결과일 뿐이에요. 원격 저장소에 푸시한 뒤의 동작이나 --hard 같은 다른 옵션은 이번에 실행하지 않았습니다.