Git으로 협업하다 보면 잘못된 커밋을 되돌려야 하는 상황이 자주 발생합니다. 이때 git reset과 git revert 중 무엇을 써야 할지 헷갈린다면, 이 글이 명확한 기준을 제시합니다. 두 명령어의 동작 원리와 실무 사용 시나리오를 비교하고, 협업 환경에서 발생할 수 있는 리스크까지 다룹니다.
 |
| Git 커밋 되돌리기 완벽 가이드: reset vs revert 실무 사용법 |
1. git reset vs git revert: 핵심 차이점
두 명령어는 커밋을 되돌린다는 목적은 같지만, 히스토리를 다루는 방식이 완전히 다릅니다.
- git reset: 커밋 히스토리 자체를 삭제합니다. 마치 그 커밋이 애초에 없었던 것처럼 기록을 지웁니다. 흔적을 남기지 않는 '삭제' 방식입니다.
- git revert: 되돌리고 싶은 커밋의 변경사항을 반대로 적용한 새로운 커밋을 생성합니다. 원본 커밋은 히스토리에 그대로 남고, "이 커밋을 취소했다"는 기록이 추가됩니다.
실무 판단 기준은 명확합니다. 협업 중인 공유 브랜치라면 revert를, 로컬 작업이거나 혼자 쓰는 브랜치라면 reset을 사용하십시오.
2. git reset 사용법과 옵션별 동작
reset은 세 가지 옵션에 따라 동작이 달라집니다. 각각의 차이를 정확히 이해해야 데이터 손실을 방지할 수 있습니다.
2-1. 기본 명령어
- 최근 커밋 1개 취소:
git reset HEAD^ - 최근 n개 커밋 취소:
git reset HEAD~3(3개 취소 시) - 특정 커밋으로 이동:
git reset <커밋해시>
2-2. 옵션별 동작 차이
- --soft: 커밋만 취소하고, 변경사항은 스테이징 영역(Staging Area)에 그대로 유지됩니다. 커밋 메시지만 다시 작성하고 싶을 때 유용합니다.
git reset --soft HEAD^ - --mixed (기본값): 커밋을 취소하고 스테이징도 해제하지만, 작업 디렉토리(Working Directory)의 파일 내용은 그대로 남습니다. 가장 안전한 기본 옵션입니다.
git reset HEAD^또는git reset --mixed HEAD^ - --hard: 커밋, 스테이징, 작업 디렉토리의 변경사항을 모두 삭제합니다. 복구가 어려우므로 신중하게 사용해야 합니다.
git reset --hard HEAD^
2-3. 원격 저장소 반영 (강제 푸시)
reset 후 원격 저장소에 반영하려면 강제 푸시(force push)가 필요합니다.
git push -f origin main- 주의: 다른 팀원이 이미 해당 커밋을 pull한 상태라면, 그들의 로컬 저장소에는 여전히 기록이 남아 있습니다. 이후 push 시 충돌이 발생할 수 있으므로 팀 전체 동의가 필요합니다.
3. git revert 사용법과 협업 시나리오
revert는 히스토리를 변경하지 않기 때문에 협업 환경에서 안전합니다. 공유 브랜치에서 커밋을 되돌릴 때 기본적으로 사용해야 하는 명령어입니다.
3-1. 기본 사용법
- 특정 커밋 취소:
git revert <커밋해시> - 커밋 메시지 자동 생성:
git revert --no-edit <커밋해시> - revert 후에는 일반 푸시로 원격 저장소에 반영 가능:
git push origin main
3-2. 실무 권장 시나리오
| 상황 | 권장 명령어 | 이유 |
|---|---|---|
| 공유 브랜치 (main, develop) | git revert | 히스토리 보존, 충돌 위험 최소화 |
| 로컬 작업 또는 개인 브랜치 | git reset | 깔끔한 히스토리 유지 가능 |
| 민감 정보(API 키 등) 노출 | git reset --hard + force push | 흔적 제거 필수 (단, 이미 공유됐다면 키 재발급 필요) |
4. 실수 복구: git reflog 활용법
reset --hard로 실수로 작업 내용을 날렸다면, git reflog로 복구할 수 있습니다. reflog는 HEAD의 모든 이동 기록을 보관합니다.
복구 절차
- 히스토리 확인:
git reflog
출력 예시:a1b2c3d HEAD@{0}: reset: moving to HEAD^ e4f5g6h HEAD@{1}: commit: 중요한 작업 - 원하는 시점으로 복구:
git reset --hard e4f5g6h - 상태 확인:
git log --oneline,git status,git diff
DevOps 관점 팁: reflog는 기본적으로 90일간 보관되지만, gc(garbage collection) 실행 시 삭제될 수 있습니다. 중요한 작업 전에는 브랜치를 백업용으로 생성해두는 습관을 권장합니다.
5. 명령어 체크리스트 및 상태 확인
실무에서 자주 사용하는 명령어를 정리했습니다. 터미널에 북마크해두고 필요할 때 참고하십시오.
로그 및 상태 확인
- 커밋 히스토리 확인:
git log - 간략 로그:
git log --oneline - 현재 상태:
git status - 변경사항 비교:
git diff - HEAD 이동 기록:
git reflog
되돌리기 명령어 요약
- 안전한 취소 (스테이징 해제):
git reset HEAD^ - 커밋만 취소 (변경사항 유지):
git reset --soft HEAD^ - 완전 삭제:
git reset --hard HEAD^ - 기록 남기며 취소:
git revert --no-edit <커밋해시> - 강제 푸시:
git push -f origin main
결론
reset은 히스토리를 삭제하는 '지우개', revert는 취소 기록을 남기는 '수정 테이프'입니다. 협업 환경에서는 revert를 기본으로 사용하고, reset + force push는 팀 동의 하에 신중하게 적용하십시오. 실수로 커밋을 날렸다면 당황하지 말고 git reflog로 복구를 시도하면 됩니다.
Action Item: 지금 당장 테스트 저장소를 만들어 git reset --soft/mixed/hard와 git revert를 각각 실행해보고, git reflog로 복구하는 과정을 직접 체험해보십시오. 실전에서 당황하지 않으려면 손에 익혀두는 것이 최선입니다.
#함께 읽으면 좋은 글
리눅스 실시간 로그 모니터링 tail -f와 grep 필터링 완벽 가이드 : 바로보기
댓글
댓글 쓰기