git reset은 커밋을 되돌릴 때 자주 쓰지만, 옵션을 잘못 고르면 파일 변경사항까지 예상과 다르게 바뀔 수 있습니다. 특히 git reset --hard는 현재 작업 중인 tracked 파일 변경사항까지 되돌릴 수 있으므로 실행 전에 현재 상태를 먼저 확인해야 합니다.
마지막 커밋만 취소하고 변경내용을 staged 상태로 남기려면 --soft, 커밋과 git add만 취소하고 수정 내용은 남기려면 --mixed, 커밋과 작업 파일 변경까지 되돌리려면 --hard를 사용합니다. 이미 push한 커밋이라면 reset보다 revert가 맞는 상황인지 먼저 검토하는 것이 안전합니다.
git reset은 HEAD, staging area, working tree 중 어디까지 되돌릴지 확인한 뒤 실행해야 합니다.
git reset은 커밋을 되돌리기 전에 범위부터 확인해야 합니다
git reset은 현재 브랜치가 가리키는 커밋 위치를 바꾸는 명령입니다. 문제는 옵션에 따라 staged 상태와 작업 폴더의 파일까지 함께 바뀔 수 있다는 점입니다.
실행 전에는 아래 3개 명령어로 현재 브랜치, 변경 파일, 최근 커밋을 먼저 확인하는 것이 좋습니다.
# 현재 변경사항 확인
git status
# 최근 커밋 확인
git log --oneline -5
# reset 전 현재 위치 백업 브랜치 만들기
git branch backup-before-reset주의할 점
git reset --hard는 커밋하지 않은 tracked 파일 변경사항까지 되돌릴 수 있습니다. 중요한 작업이 남아 있다면 reset 전에 백업 브랜치를 만들거나 git stash로 임시 저장한 뒤 진행하는 것이 안전합니다.
자주 만나는 git reset 상황
git reset은 항상 오류 메시지를 보여주는 명령이 아닙니다. 실제로는 명령 실행 후 파일 상태가 예상과 다르게 보여서 문제가 생기는 경우가 많습니다.
| 상황 | 자주 쓰는 명령 | 확인할 점 |
|---|---|---|
| 커밋만 취소하고 싶을 때 | git reset --soft HEAD~1 |
변경 파일이 staged 상태로 남습니다. |
| 커밋과 add를 취소하고 싶을 때 | git reset HEAD~1 |
기본값은 --mixed입니다. |
| 파일 변경까지 되돌리고 싶을 때 | git reset --hard HEAD~1 |
작업 파일 변경이 사라질 수 있습니다. |
커밋 해시나 기준을 잘못 입력하면 아래처럼 revision을 찾을 수 없다는 메시지가 나올 수 있습니다.
fatal: ambiguous argument 'HEAD~1': unknown revision or path not in the working tree.이 경우에는 바로 다른 reset 명령을 반복하지 말고 git status, git log --oneline, git reflog 순서로 현재 저장소 상태를 확인합니다.
git reset soft, mixed, hard 차이
git reset 옵션은 HEAD, staging area, working tree 중 어디까지 되돌릴지로 구분하면 이해하기 쉽습니다.
| 옵션 | 바뀌는 범위 | 주로 쓰는 상황 |
|---|---|---|
--soft |
HEAD만 이동 | 커밋만 취소하고 바로 다시 커밋하고 싶을 때 |
--mixed |
HEAD와 staging area 변경 | 커밋과 git add를 취소하고 파일 수정은 남길 때 |
--hard |
HEAD, staging area, working tree 변경 | 작업 파일 변경까지 이전 상태로 되돌릴 때 |
git reset HEAD~1처럼 옵션을 생략하면 기본값은 --mixed입니다. 그래서 커밋은 취소됐지만 파일 수정은 작업 폴더에 남아 있는 상태가 됩니다.
HEAD, staging area, working tree 기준으로 이해하기
git reset은 Git의 세 영역을 기준으로 생각하면 실수를 줄일 수 있습니다.
- HEAD: 현재 브랜치가 가리키는 커밋 위치입니다.
- staging area:
git add로 커밋 준비가 된 영역입니다. - working tree: 실제 파일을 수정하고 있는 작업 폴더입니다.
--soft는 HEAD만 움직입니다. --mixed는 HEAD와 staging area를 바꿉니다. --hard는 working tree까지 바꾸므로 현재 파일 상태가 바뀔 수 있습니다.
핵심 정리
커밋만 다시 만들고 싶다면 --soft, add 상태까지 풀고 다시 고르고 싶다면 --mixed, 작업 파일까지 되돌려도 되는 상황에서만 --hard를 사용합니다.
마지막 커밋만 취소하고 수정 내용은 남기기
마지막 커밋 메시지를 잘못 썼거나 커밋을 다시 나누고 싶다면 --soft 또는 --mixed를 먼저 검토합니다. 두 옵션은 작업 파일 수정 내용을 남긴다는 점에서 --hard보다 안전합니다.
수정 내용을 staged 상태로 남기기
git reset --soft HEAD~1이 명령은 마지막 커밋만 취소하고 변경 파일을 git add된 상태로 남깁니다. 커밋 메시지만 다시 쓰거나 작은 수정 후 바로 커밋할 때 편합니다.
git status
git commit -m "새 커밋 메시지"수정 내용을 unstaged 상태로 남기기
git reset --mixed HEAD~1또는 아래처럼 옵션을 생략해도 됩니다.
git reset HEAD~1이 명령은 마지막 커밋과 staging 상태를 취소하지만, 파일 수정 내용은 작업 폴더에 남깁니다. 변경 파일을 다시 고르고 싶을 때 적합합니다.
git reset --hard는 실행 전 확인이 필요합니다
git reset --hard는 HEAD, staging area, working tree를 모두 지정한 커밋 상태로 맞춥니다. 아직 커밋하지 않은 tracked 파일 변경사항이 있다면 현재 작업이 사라진 것처럼 보일 수 있습니다.
실행 전에는 아래 순서로 현재 상태를 남겨두는 것이 좋습니다.
# 현재 변경사항 확인
git status
# 최근 커밋 확인
git log --oneline -5
# 현재 위치를 백업 브랜치로 남기기
git branch backup-before-hard-reset현재 작업을 임시 저장해야 한다면 git stash를 먼저 사용할 수 있습니다.
git stash push -m "reset 전 임시 저장"
git reset --hard HEAD~1특정 커밋으로 되돌릴 때는 커밋 해시를 사용합니다.
git reset --hard 커밋해시이 명령은 되돌릴 기준이 정확할 때만 실행해야 합니다. 기준 커밋이 헷갈린다면 git log --oneline --graph --decorate로 브랜치 흐름을 먼저 확인합니다.
잘못 reset했을 때 되돌리는 순서
이미 git reset을 실행했다면 먼저 git reflog로 HEAD가 이전에 어디를 가리켰는지 확인합니다. reflog는 최근 HEAD 이동 기록을 보여주기 때문에, reset 전 위치를 찾는 데 도움이 됩니다.
git reflog출력은 아래와 비슷하게 보일 수 있습니다.
a1b2c3d HEAD@{0}: reset: moving to HEAD~1
e4f5g6h HEAD@{1}: commit: 로그인 오류 처리 추가
h7i8j9k HEAD@{2}: commit: 초기 설정 추가잘못 reset하기 전 위치가 HEAD@{1} 또는 특정 커밋 해시로 보인다면 해당 위치로 다시 이동할 수 있습니다.
git reset --hard e4f5g6h다만 현재 작업 폴더 상태도 함께 바뀔 수 있으므로, 지금 상태를 남기고 싶다면 바로 hard reset하지 말고 백업 브랜치를 먼저 만듭니다.
git branch backup-current-state
git reset --hard e4f5g6h복구할 때 주의할 점
커밋으로 남아 있던 기록은 git reflog에서 찾을 수 있는 경우가 많습니다. 하지만 커밋하지 않은 작업 파일 변경은 상황에 따라 복구가 어려울 수 있으므로 --hard 실행 전 백업이 중요합니다.
이미 push한 커밋은 reset보다 revert를 먼저 검토합니다
혼자 쓰는 로컬 브랜치라면 git reset으로 커밋을 정리할 수 있습니다. 하지만 이미 원격 저장소에 push한 커밋을 reset하면 다른 사람이 받은 커밋 기록과 달라질 수 있습니다.
협업 브랜치에서는 기존 커밋 기록을 지우는 방식보다, 되돌리는 새 커밋을 만드는 git revert가 더 안전한 경우가 많습니다.
# 특정 커밋의 변경사항을 되돌리는 새 커밋 만들기
git revert 커밋해시이미 push한 커밋을 reset한 뒤 강제 push해야 하는 상황이라면 개인 브랜치인지, 팀원에게 공유된 브랜치인지, 원격 저장소의 최신 상태가 바뀌었는지 먼저 확인해야 합니다.
# 협업 브랜치에서는 주의해서 사용
git push --force-with-lease--force-with-lease도 원격 기록을 바꿀 수 있으므로 팀 규칙을 먼저 확인한 뒤 사용합니다.
Windows, Mac, Linux에서 다른 점
git reset 명령의 의미는 Windows, Mac, Linux에서 같습니다. 다만 터미널 환경, 파일 경로, 줄바꿈 설정, 대소문자 구분 때문에 변경 파일이 다르게 보일 수 있습니다.
| 환경 | 확인할 점 | 추천 명령 |
|---|---|---|
| Windows | Git Bash, PowerShell, VSCode 터미널 중 어디에서 실행하는지 확인합니다. | git status |
| Mac | zsh 터미널과 VSCode 내장 터미널의 현재 폴더가 같은지 확인합니다. | pwd |
| Linux | 권한 문제나 파일명 대소문자 차이로 변경 파일이 다르게 보일 수 있습니다. | git log --oneline -5 |
reset을 실행하기 전에 현재 저장소 위치와 브랜치를 확인하면 다른 폴더에서 명령을 실행하는 실수를 줄일 수 있습니다.
# 현재 저장소 위치 확인
pwd
# 현재 브랜치와 변경사항 확인
git status
# 최근 커밋 확인
git log --oneline -5VSCode에서 reset하기 전 확인할 것
VSCode Source Control 화면에서 reset을 실행해도 Git 명령의 기본 원리는 같습니다. 다만 GUI 메뉴에서는 어떤 옵션으로 reset되는지 헷갈릴 수 있으므로 중요한 작업 전에는 터미널에서 상태를 먼저 확인하는 편이 안전합니다.
- 왼쪽 Source Control에 수정 파일이 남아 있는지 확인합니다.
- 터미널에서
git status를 실행합니다. - 되돌릴 기준 커밋을
git log --oneline으로 확인합니다. --hard가 필요한 상황인지,--soft나--mixed로 충분한지 판단합니다.- 필요하면
git branch backup-before-reset으로 백업 브랜치를 만듭니다.
작업 파일을 남겨야 한다면 --hard 대신 --soft, --mixed, 또는 git stash를 먼저 고려합니다.
reset 전 안전 체크리스트
git reset 실행 전 확인
□ git status로 커밋하지 않은 변경사항을 확인했는가?
□ git log --oneline -5로 되돌릴 기준 커밋을 확인했는가?
□ 이미 원격 저장소에 push한 커밋인지 확인했는가?
□ 협업 브랜치라면 reset 대신 revert가 맞는지 검토했는가?
□ --hard 실행 전 백업 브랜치나 stash를 만들었는가?
□ reset 후 다시 push해야 한다면 팀 규칙을 확인했는가?
자주 쓰는 git reset 명령어 모음
아래 명령어는 reset 전에 현재 상태를 확인한 뒤 사용합니다. 특히 --hard와 강제 push는 작업 파일과 원격 기록에 영향을 줄 수 있으므로 실행 전 한 번 더 확인하는 것이 좋습니다.
# 마지막 커밋만 취소하고 staged 상태로 남기기
git reset --soft HEAD~1
# 마지막 커밋과 git add를 취소하고 파일 수정은 남기기
git reset --mixed HEAD~1
# mixed는 기본값이라 아래 명령과 같음
git reset HEAD~1
# 마지막 커밋과 작업 파일 변경까지 되돌리기
git reset --hard HEAD~1
# 특정 커밋으로 되돌리기
git reset --hard 커밋해시
# reset 기록 확인
git reflog
# reset 전 백업 브랜치 만들기
git branch backup-before-reset공식 자료로 더 확인하기
git reset은 옵션별 동작 범위가 중요한 명령입니다. 실제 프로젝트에서 실행하기 전에는 Git 공식 문서와 Pro Git 설명을 함께 확인하면 HEAD, index, working tree의 관계를 더 정확히 이해할 수 있습니다.
git reset의 옵션, 모드, 경로 지정 방식, HEAD 이동 동작을 공식 기준으로 확인할 수 있습니다.
reset이 HEAD, index, working directory에 어떤 순서로 영향을 주는지 그림과 함께 이해할 수 있습니다.
Pro Git에서 reset 동작 구조 확인하기reset 후 이전 HEAD 위치를 찾거나, 잘못 이동한 커밋을 복구할 때 확인할 수 있는 reflog 사용법을 안내합니다.
Git 공식 문서에서 reflog 복구 흐름 확인하기함께 보면 좋은 글
git reset --hard 전 작업 파일을 잃지 않도록 stash로 임시 저장하는 흐름을 함께 확인할 수 있습니다.
자주 묻는 질문
git reset은 되돌리는 명령이지만, 실행 전 현재 상태와 되돌릴 범위를 확인해야 안전하게 사용할 수 있습니다.
댓글