-
git commit 되돌리기 — 로컬부터 push 이후까지 완벽 대응카테고리 없음 2026. 3. 22. 22:26
들어가며
개발을 하다 보면 커밋을 잘못 남기는 상황이 자주 발생한다.
실수로 민감한 정보를 커밋했거나, 직전 커밋 메시지가 마음에 들지 않거나, 아예 여러 커밋을 한꺼번에 없애야 할 때도 있다.
git은 이런 상황을 위한 다양한 되돌리기 명령어를 제공하며, 상황에 따라 올바른 명령어를 선택하는 것이 중요하다.이 글에서는 로컬 커밋을 되돌리는 방법부터 이미 원격 저장소에 push한 커밋을 안전하게 처리하는 방법까지 단계별로 정리한다.
협업 환경에서 팀원에게 피해를 주지 않는 방법도 함께 다루므로, 상황에 맞는 방법을 골라 사용하면 된다.
git reset — 로컬 커밋 되돌리기
git reset은 현재 브랜치의 HEAD 포인터를 특정 커밋으로 이동시키는 명령어다.
로컬에서만 작업 중이고 아직 push하지 않은 커밋에 사용하기 적합하다.--soft,--mixed,--hard세 가지 옵션에 따라 동작이 달라진다.--soft: 커밋만 취소, 변경사항 스테이징 유지
git reset --soft HEAD~1마지막 커밋을 취소하되 변경된 파일은 스테이징 영역(index)에 그대로 남긴다.
커밋 메시지만 다시 작성하고 싶거나, 여러 커밋을 하나로 합치고 싶을 때 유용하다.
파일 내용 자체는 전혀 바뀌지 않는다.--mixed: 커밋 취소 + 스테이징 해제 (기본값)
git reset --mixed HEAD~1 # 또는 단순히 git reset HEAD~1커밋을 취소하고 변경사항을 언스테이징(working directory)으로 되돌린다.
파일 내용은 그대로 유지되지만git add를 다시 해야 스테이징된다.
특정 파일만 선택적으로 다시 스테이징하고 싶을 때 사용한다.--hard: 커밋 취소 + 변경사항 완전 삭제
git reset --hard HEAD~1커밋을 취소하고 해당 커밋 이후의 모든 변경사항을 완전히 삭제한다.
working directory까지 되돌아가므로 저장되지 않은 변경사항은 복구할 수 없다.
사용 전에 반드시 필요한 파일을 백업하거나 stash해 두어야 한다.여러 커밋을 한꺼번에 되돌리려면
HEAD~N형태로 숫자를 지정하거나, 커밋 해시를 직접 입력할 수 있다.# 3개 커밋 되돌리기 git reset --hard HEAD~3 # 특정 커밋 해시로 되돌리기 git reset --hard abc1234
git revert — 히스토리를 보존하며 되돌리기
git revert는 특정 커밋의 변경사항을 되돌리는 새로운 커밋을 생성하는 명령어다.
기존 커밋 히스토리를 수정하지 않고 "되돌린다"는 기록 자체를 새 커밋으로 남긴다.
이미 push한 커밋이거나 협업 중인 브랜치에서는revert를 사용하는 것이 안전하다.# 직전 커밋 되돌리기 git revert HEAD # 특정 커밋 되돌리기 git revert abc1234 # 커밋 메시지 편집 없이 바로 커밋 git revert --no-edit HEADgit revert를 실행하면 기본적으로 에디터가 열려 새 커밋 메시지를 입력하게 된다.--no-edit옵션을 사용하면 에디터 없이 기본 메시지로 즉시 커밋된다.
여러 커밋을 연속으로 되돌리려면 범위를 지정할 수도 있다.# 최근 3개 커밋 순서대로 revert git revert HEAD~2..HEADrevert는 원래 커밋의 반대 패치를 적용하는 방식이므로, 충돌이 발생할 수 있다.
충돌이 생기면 파일을 수동으로 수정한 뒤git revert --continue로 진행하면 된다.
이미 push한 경우 — 안전한 revert
원격 저장소에 이미 push한 커밋은 되도록
git revert로 처리하는 것이 원칙이다.
히스토리를 유지한 채 되돌린 기록을 남기므로 팀원들이 혼란 없이 변경 사항을 추적할 수 있다.
revert 커밋을 생성한 후 평소처럼 push하면 된다.# 원격에 push된 커밋을 revert git revert HEAD git push origin main특정 커밋만 취소하고 싶다면 해당 커밋 해시를 지정한다.
git log --oneline # 커밋 해시 확인 git revert abc1234 git push origin main이 방식은 기존 히스토리를 전혀 변경하지 않으므로, 다른 팀원들이 이미 pull한 상태여도 충돌 없이 적용할 수 있다.
다만 민감한 정보(패스워드, API 키 등)가 포함된 커밋을 revert해도 git 히스토리에는 원본이 남아 있음을 주의해야 한다.
민감 정보 노출 시에는 히스토리 자체를 재작성하는 별도 처리가 필요하다.
이미 push한 경우 — force push로 강제 덮어쓰기
git reset으로 로컬 히스토리를 수정한 뒤 원격에 강제로 push하는 방법도 있다.
이 방법은 히스토리를 실제로 삭제하므로 단독으로 작업하는 브랜치나 긴급 상황에서만 사용해야 한다.--force대신--force-with-lease를 사용하면 다른 사람이 중간에 push했는지 먼저 확인해 실수를 방지할 수 있다.# 로컬에서 커밋 되돌리기 git reset --hard HEAD~1 # 안전한 force push git push --force-with-lease origin main # 주의: 아래는 더 위험한 방식 (원격 상태 확인 없이 덮어씀) # git push --force origin main--force-with-lease는 내가 마지막으로 fetch한 이후 원격 브랜치에 새 커밋이 추가됐다면 push를 거부한다.
이를 통해 다른 팀원의 커밋을 실수로 덮어쓰는 사고를 예방할 수 있다.
force push 후에는 반드시 팀원들에게 알려서 로컬 브랜치를git fetch및git reset으로 동기화하도록 해야 한다.# 팀원이 force push 이후 실행해야 할 명령어 git fetch origin git reset --hard origin/main
협업 환경에서의 주의사항
force push는 공유 브랜치(main, develop 등)에서 사용할 때 특히 위험하다.
팀원이 이미 해당 커밋을 pull한 상태라면, 그 팀원의 로컬 브랜치와 원격 브랜치 히스토리가 달라져 충돌이 발생한다.
가능하면 공유 브랜치에는git revert를 사용하고, force push는 개인 feature 브랜치에서만 사용하는 것을 권장한다.팀에서 force push를 허용하는 경우라도 반드시 다음 절차를 따르는 것이 좋다.
1. 팀원들에게 해당 브랜치 작업 중단 요청 2. 로컬에서 git reset 실행 3. git push --force-with-lease 실행 4. 팀원들에게 git fetch + git reset --hard origin/<브랜치> 안내또한 GitHub, GitLab 등 대부분의 원격 저장소는 기본적으로 main/master 브랜치의 force push를 보호(branch protection)로 막아두고 있다.
설정을 해제하지 않으면 force push가 거부되며, 이는 의도된 안전장치이므로 무분별하게 해제하지 않는 것이 좋다.
상황별 방법 선택 가이드
아래 표를 참고해 현재 상황에 맞는 방법을 선택하면 된다.
상황 추천 방법 명령어 아직 push 안 함, 커밋만 취소 git reset --soft git reset --soft HEAD~1아직 push 안 함, 스테이징도 취소 git reset --mixed git reset HEAD~1아직 push 안 함, 변경사항 완전 삭제 git reset --hard git reset --hard HEAD~1이미 push, 히스토리 유지 필요 git revert git revert HEAD이미 push, 히스토리 삭제 필요 (개인 브랜치) force push git push --force-with-lease협업 중인 공유 브랜치 git revert git revert abc1234핵심 원칙은 단순하다.
혼자 쓰는 로컬 또는 개인 브랜치라면git reset, 공유된 히스토리에서는git revert를 기본으로 선택하면 대부분의 상황을 무난하게 처리할 수 있다.
마치며
git의 되돌리기 명령어는 강력하지만 잘못 사용하면 팀 전체에 혼란을 줄 수 있다.
git reset은 로컬에서 빠르게 수정할 때,git revert는 안전하게 히스토리를 남길 때 사용하는 것이 기본 원칙이다.
force push는 최후의 수단으로만 사용하고, 반드시 팀원과 소통한 뒤 진행해야 한다.이 글에서 소개한 방법들을 상황에 맞게 활용하면, 실수로 남긴 커밋을 깔끔하게 처리하고 프로젝트 히스토리를 건강하게 유지할 수 있다.
git에 익숙해질수록 되돌리기를 두려워하지 않고 자신 있게 사용할 수 있게 될 것이다.