Git에서 방금 한 실수 되돌리기 — 30초 진단과 안전 명령어

2026년 7월 31일 기준, Git에서 방금 한 실수를 되돌리려면 명령어부터 찾기보다 add·commit·push 중 어디까지 진행했는지 먼저 확인해야 합니다. Git 2.55.0 공식 문서를 기준으로 상황에 맞는 안전한 명령어를 빠르게 고를 수 있게 정리했습니다.

같은 실수처럼 보여도 push 전후에 따라 해결 방법과 위험도가 크게 달라집니다.

이런 증상입니까

엉뚱한 파일을 git add했거나 마지막 커밋 메시지를 잘못 작성했다면 로컬 상태만 바로잡으면 됩니다.

커밋을 너무 일찍 했지만 아직 push하지 않았다면 수정 내용은 남겨 두고 커밋만 취소할 수 있습니다.

커밋을 이미 push했다면 공유 이력을 지우지 않고 반대 변경을 새 커밋으로 남기는 편이 안전합니다.

현재 상태를 먼저 확인하지 않으면 보존하려던 코드까지 지울 수 있습니다.

30초 진단

아래 명령으로 작업 파일, 스테이징 영역, 최근 커밋을 차례로 확인합니다.

git --version
git status
git diff
git diff --staged
git log --oneline -5

• 잘못 add한 파일만 빼려는 경우 — git restore --staged
• 마지막 커밋 메시지만 고치려는 경우 — push 전 git commit --amend --only
• 마지막 커밋만 취소하고 수정 내용은 남기려는 경우 — push 전 git reset --soft
• 이미 push한 커밋을 되돌리려는 경우 — 공유 브랜치에서는 git revert
• Git 2.23 미만인 경우 — restore 대신 기존 reset 방식 확인

개인적으로는 복구 명령을 외우는 것보다 push 여부를 먼저 확인하는 습관이 더 중요하다고 봅니다.

728x90

가장 빠른 해결

아직 push하지 않았다면 실수 유형에 맞는 명령 하나를 고르면 됩니다.

# 잘못 add한 파일만 스테이징 취소
git restore --staged -- path/to/file

# 최신 커밋 메시지만 수정
git commit --amend --only -m "새 커밋 메시지"

# 최신 커밋을 취소하고 변경은 스테이징 상태로 유지
git reset --soft HEAD~1

git restore --staged는 작업 파일의 수정 내용을 남깁니다. git reset --soft HEAD~1도 취소한 커밋의 변경을 스테이징 영역과 작업 폴더에 보존합니다.

이미 push한 뒤라면 공유 이력을 유지하는 revert가 기본 선택입니다.

git status
git revert HEAD
git push

병합 커밋을 되돌리려면 별도로 mainline을 지정해야 하므로 위 명령부터 실행하지 말고 실제 커밋 구조를 먼저 확인해야 합니다.

⚠️ 위험 경고: git restore -- path/to/file은 스테이징 취소가 아니라 작업 파일 복원입니다. 스테이징 이후의 수정 내용이 사라질 수 있습니다.

⚠️ 위험 경고: git reset --hard HEAD~1는 추적 파일의 변경을 삭제할 수 있으며, 이미 push한 뒤 강제 push하면 공유 이력까지 다시 쓰게 됩니다.

반응형

왜 이런 일이 생깁니까

Git은 작업 폴더, 스테이징 영역, 커밋 이력을 각각 다른 상태로 관리합니다.

restore --staged는 스테이징 영역만 바꾸지만 reset은 옵션에 따라 브랜치 위치와 스테이징 상태까지 옮깁니다.

amend도 기존 커밋을 직접 고치는 명령이 아니라 마지막 커밋을 대체할 새 커밋을 만듭니다. 메시지만 바꿔도 커밋 ID가 달라집니다.

revert는 기존 커밋을 삭제하지 않고 반대 변경을 담은 새 커밋을 추가하므로 이미 공유한 브랜치에 적합합니다.

[이미지 3 자리]

재발 방지

다음 세 단계만 지켜도 위험한 명령을 잘못 선택할 가능성이 크게 줄어듭니다.

1. git status와 git diff --staged로 되돌릴 범위를 확인합니다.
2. push 전이라면 수정 내용을 보존하는 restore --staged, amend, reset --soft부터 검토합니다.
3. push 후이거나 다른 사람이 사용하는 브랜치라면 revert를 선택하고 저장소 정책을 확인합니다.

reset --hard나 강제 push가 필요해 보인다면 명령 실행을 멈추고 보존할 변경과 협업 여부부터 다시 확인해야 합니다.