개발도구/Git

Git 되돌리기 총정리: reset / revert / restore 차이를 상황별로 정리합니다

zumsim 2026. 1. 14. 20:23
728x90
반응형

Git을 쓰다 보면 “방금 한 커밋을 취소하고 싶다”, “이미 푸시했는데 되돌려야 한다”, “스테이지만 취소하고 싶다” 같은 상황이 반드시 옵니다. 이때 명령을 잘못 쓰면 히스토리가 꼬이거나 협업에 문제가 생깁니다. 이 글은 가장 자주 겪는 6가지 상황을 기준으로 안전한 해결법을 정리합니다.

핵심 규칙
이미 원격(origin)에 푸시한 커밋은 보통 revert가 안전합니다
② 로컬에서만 작업 중이면 reset/restore로 깔끔하게 정리할 수 있습니다

상황 1) 방금 커밋 메시지만 바꾸고 싶습니다

git commit --amend
  

※ 이미 푸시했다면 협업 영향이 있으므로 주의해야 합니다.

상황 2) 마지막 커밋 자체를 없애고(되돌리고) 싶습니다 (푸시 전)

변경 내용은 남기고 커밋만 취소합니다.

git reset --soft HEAD~1
  

변경 내용까지 작업트리에서 모두 되돌립니다(주의).

git reset --hard HEAD~1
  

상황 3) add(스테이징)만 취소하고 싶습니다

전체 파일 스테이징 취소입니다.

git restore --staged .
  

특정 파일만 스테이징 취소합니다.

git restore --staged path/to/file
  

상황 4) 작업 중인 변경사항을 버리고 싶습니다(파일을 원래대로)

git restore .
  

※ 작업 내용을 버리는 명령이므로 실행 전 반드시 확인해야 합니다.

상황 5) 이미 푸시한 커밋을 “안전하게” 되돌려야 합니다

협업 중이라면 히스토리를 강제로 바꾸는 것보다, 되돌리는 커밋을 새로 만드는 revert가 안전합니다.

git revert 커밋해시
  

상황 6) 특정 커밋만 빼고 나머지는 유지하고 싶습니다

여러 커밋 중 하나만 “되돌리기”는 revert가 가장 깔끔합니다. 충돌이 나면 충돌 해결 후 continue로 마무리합니다.

git revert 커밋해시
# 충돌 해결 후
git revert --continue
  

현업에서 자주 하는 안전 체크

  • 실행 전 git status로 현재 상태를 확인합니다.
  • 되돌리기 전에 브랜치를 하나 더 따서 작업하면 리스크가 줄어듭니다.
  • 팀 작업 중 “force push”는 원칙적으로 피하고, 불가피하면 팀에 공유합니다.

공식 문서 링크


 

728x90
반응형