이 편은 6편 — reset·revert·reflog로 되돌리는 안전한 복구의 기술에서 정리한 되돌리기 도구를 실제로 터지는 상황에 적용해 보는 실전편입니다. 각 시나리오는 "무엇을 먼저 확인하는가"부터 시작합니다.
시나리오 1. main에 직접 커밋해버렸다 (push 전)
git log --oneline -3 # 1. 확인
git branch feature/my-work # 2. 현재 위치에 브랜치 생성 (커밋 보존)
git reset --hard origin/main # 3. main을 원격 상태로 되돌림
git switch feature/my-work # 4. 브랜치에서 계속 작업브랜치를 먼저 만드는 순서가 핵심입니다. 포인터를 하나 더 박아둔 뒤 main을 움직이므로 커밋이 고아가 되지 않습니다.
시나리오 2. main에 직접 push해버렸다
git revert <commit> # 되돌리는 커밋 생성
git push origin mainreset --hard + --force는 쓰지 마세요. 이미 남이 받아갔을 수 있습니다.
시나리오 3. reset --hard로 커밋을 날렸다
git reflog # 1. 날린 커밋 해시 찾기
git branch rescue HEAD@{1} # 2. 그 지점에 브랜치 생성
git switch rescue # 3. 확인
git log --oneline # 4. 맞는지 검증시나리오 4. 잘못된 브랜치에서 작업 중이었다 (커밋 전)
git stash -u # 변경 임시 저장 (untracked 포함)
git switch correct-branch
git stash pop시나리오 5. 잘못된 브랜치에 커밋했다 (push 전)
git log --oneline -1 # 1. 커밋 해시 확인
git switch correct-branch
git cherry-pick <해시> # 2. 먼저 올바른 브랜치에 복사
git switch - # 3. 원래(잘못된) 브랜치로 복귀
git status # 4. 커밋 안 된 변경이 없는지 확인 ★
git reset --hard HEAD~1 # 5. 그제서야 제거옮기고 나서 지웁니다. 시나리오 1과 같은 원칙입니다 — 커밋이 두 곳에 있는 시점을 만들어두고 원본을 치우세요.
시나리오 6. 동료가 force push해서 내 커밋이 사라졌다
git reflog # 내 로컬 HEAD 이동 기록 — 내 커밋은 살아있음 ★
git reflog show origin/main # 동료의 force push 전 원격 상태도 여기 남는다 ★
git branch rescue <위에서 찾은 해시> # 숫자가 아니라 눈으로 확인한 해시를 쓰세요
# → 동료와 상의 후 cherry-pick 또는 merge로 복구분산 버전 관리의 진가가 나오는 순간입니다. 원격이 파괴돼도 누군가의 로컬에 완전한 복사본이 남아있습니다.
시나리오 7. .env를 커밋해서 push했다
# 1. 키를 즉시 폐기하고 재발급 ★ 가장 먼저
# 2. 추적 해제
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "chore: .env 추적 해제"
git push
# 3. 필요하면 히스토리 정리 (7편 5.7) — 팀 공지 필수3번의 히스토리 정리 절차는 7편의 민감 정보 제거에 있습니다.
시나리오 8. merge 충돌이 감당이 안 된다
git merge --abort # 병합 전으로 완전 복귀 ★
# 또는
git rebase --abortGit의 병합/리베이스는 언제든 중단 가능하도록 설계돼 있습니다. 당황해서 파일을 마구 고치지 말고 일단 abort하고 다시 시작하세요.
시나리오 9. "detached HEAD 상태입니다"
특정 커밋을 직접 체크아웃하면 브랜치가 아닌 커밋에 HEAD가 붙습니다. 여기서 커밋하면 어느 브랜치에도 속하지 않아 나중에 사라집니다.
git switch -c temp-branch # 여기 작업을 살리고 싶다면 브랜치 생성
git switch main # 그냥 빠져나오려면 (커밋한 게 없을 때)시나리오 10. push가 거부당했다 (rejected)
! [rejected] main -> main (fetch first)원격에 내가 모르는 커밋이 있다는 뜻입니다.
git fetch origin
git log --oneline HEAD..origin/main # 뭐가 들어왔는지 확인 ★
git merge origin/main # 또는 git rebase origin/main
git push절대 --force로 해결하지 마세요. 그 거부는 Git이 남의 작업을 지키고 있다는 신호입니다.
시나리오 11. 커밋 작성자 정보가 틀렸다
# 마지막 커밋만
git commit --amend --author="Name <email@example.com>" --no-edit
# 여러 커밋 (히스토리 재작성, push 전에만)
git rebase -i HEAD~5 # 각 커밋을 edit 후 --amend시나리오 12. 대용량 파일을 커밋해서 push가 안 된다
# 아직 push 전이라면
git reset --soft HEAD~1
git rm --cached big-file.zip
echo "big-file.zip" >> .gitignore
git add .gitignore
git commit -m "feat: 기능 추가"GitHub는 파일당 100 MiB를 넘는 파일의 push를 차단하고, 50 MiB를 넘으면 경고를 띄웁니다(브라우저 업로드는 25 MiB). 이미 히스토리에 들어갔다면 7편에서 다룬 git-filter-repo나 Git LFS로 옮겨야 합니다.