git reset으로 커밋 되돌리기: --soft·--mixed·--hard 차이와 복구 실무 가이드

git reset으로 커밋 되돌리기: --soft·--mixed·--hard 차이와 복구 실무 가이드

git reset은 커밋 취소, 이력 재정리, 로컬 초기화에서 가장 많이 쓰는 명령어다. 옵션별로 HEAD, index, working tree에 미치는 영향이 달라 정확한 구분이 필요하다. 초보~중급 개발자가 바로 적용할 수 있도록 명령어 흐름, 옵션 선택 기준, 복구 절차를 실무 중심으로 설명한다.

공식 Git 로고 (출처: git-scm.com)

git reset 기본 사용 패턴

git log --oneline -n 5
git reset --mixed HEAD~1
git add -p
git commit -m "fix(api): split validation and response mapping"

자주 쓰는 옵션 3~6개

항목	의미	언제 쓰는지(실무 상황)
--soft	HEAD만 이동하고 스테이징/파일은 유지	직전 커밋을 다시 작성할 때
--mixed	HEAD와 index를 되돌리고 파일은 유지(기본)	커밋 취소 후 add를 다시 구성할 때
--hard	HEAD, index, working tree를 모두 되돌림	로컬 실험 변경을 완전히 폐기할 때
--keep	보존 가능한 로컬 변경은 유지하며 리셋	수정본 손실을 줄이며 커밋만 이동할 때
HEAD~N	N개 이전 커밋으로 이동	최근 여러 커밋을 한 번에 정리할 때

실무 적용 순서

1) 실행 전 상태 확인

git status와 git log로 현재 위치를 확인한다. 특히 원격 공유 브랜치인지, 로컬 전용 브랜치인지 먼저 판단해야 안전하다.

2) 목적에 맞는 옵션 선택

동일 명령어라도 옵션에 따라 이력 보존, 충돌 위험, 협업 영향이 달라진다. 팀 정책과 배포 단계에 맞춰 옵션을 고른다.

3) 실행 후 검증

명령 실행 뒤에는 status, diff, 테스트를 통해 결과를 검증한다. 필요하면 즉시 복구 명령(reflog, revert, stash)을 연계한다.

문제 상황 1개

상황: git reset --hard 실행 후 방금 작업한 코드가 사라졌다.
원인: 커밋이나 stash 없이 working tree를 강제 폐기했다.
해결: git reflog로 이전 HEAD 해시를 찾고 git checkout <hash> 또는 복구 브랜치를 생성한다.
예방 팁: hard reset 전에는 git stash push -u로 임시 백업을 남긴다.

참고/출처

공식 문서: git-reset manual
공식 문서: Pro Git - Reset Demystified
신뢰 자료: GitHub Docs - About git reset