코드를 열심히 수정하고 자신 있게 커밋까지 마쳤는데, 갑자기 치명적인 오류가 뿜어져 나오며 서비스 전체가 멈춰버린 경험, 다들 한 번쯤 있으시죠? 저도 신입 시절에 배포 직전 브랜치를 엉망으로 꼬아놓고 식은땀을 뻘뻘 흘렸던 아찔한 기억이 아직도 생생해요. 😅
급한 마음에 인터넷을 검색해보면 누군가는 git reset을 쓰라고 하고, 또 다른 글에서는 절대 쓰지 말고 git revert를 써야 한다고 해서 더 혼란스러우셨을 텐데요. 결론부터 말씀드리면 내 소스코드가 현재 ‘로컬 저장소’에만 있는지, 아니면 팀원들과 공유하는 ‘원격 저장소(GitHub 등)’에 이미 푸시되었는지에 따라 정답이 완전히 달라집니다. 오늘은 내 상황에 딱 맞는 되돌리기 기법을 완벽하게 마스터해 볼게요!
1. Git 되돌리기의 3대 축: 개념부터 잡기 🤔
Git에서 과거의 상태로 코드를 되돌리는 방법은 크게 세 가지로 나뉩니다. 각 명령어가 동작하는 원리를 이해하려면 Git의 3대 작업 공간인 작업 디렉터리(Working Tree), 스테이징 영역(Index/Staging Area), 그리고 저장소 히스토리(Repository Commit)를 어떻게 다루는지 알아야 해요.
- git reset: 타임머신을 타고 과거로 시간을 되돌리는 방식입니다. 지정한 커밋 이후의 변경 기록 자체를 히스토리에서 지워버리며 HEAD 포인터를 강제로 이동시킵니다.
- git revert: 실수를 인정하고 반대 작업을 수행하는 새로운 커밋을 덧붙이는 방식입니다. 과거 기록은 그대로 둔 채 “이전 작업을 취소함”이라는 내역을 신규 커밋으로 발행합니다.
- git checkout (또는 switch/restore): 현재 브랜치의 기록을 건드리지 않고, 특정 커밋 시점의 파일 상태만 잠시 들여다보거나 분기할 때 사용합니다.
협업의 황금률은 간단합니다. “혼자 작업하는 로컬 브랜치라면 reset, 이미 원격 저장소에 push해 팀원과 공유 중이라면 무조건 revert!” 이것만 머릿속에 기억해 두셔도 대형 참사의 90%는 예방할 수 있어요.
2. Reset vs Revert vs Checkout 한눈에 비교하기 📊
세 가지 명령어의 차이점을 표로 일목요연하게 비교해 보았습니다. 상황에 맞춰 어떤 도구를 꺼내 들어야 할지 확인해 보세요.
| 명령어 | 커밋 히스토리 변화 | 원격(협업) 안전성 | 추천 권장 상황 |
|---|---|---|---|
| git reset | 과거 커밋 이후 내역 삭제 (되돌림) | 위험 (Push 후 금지) | 로컬에서 깔끔하게 흔적을 지우고 다시 짤 때 |
| git revert | 과거 기록 보존 + 취소용 신규 커밋 추가 | 매우 안전 (충돌 없음) | 이미 GitHub 등에 push된 배포 코드를 취소할 때 |
| git checkout | 히스토리 변경 없음 (단순 포인터 이동) | 안전 (조회 전용) | 예전 버전 상태로 잠깐 가서 코드를 빌드해볼 때 |
git reset --hard 명령은 현재 워킹 디렉터리에서 작업 중이던 커밋되지 않은 모든 수정 파일을 예고 없이 영구 삭제합니다. 실행하기 전에 반드시 git stash로 임시 보관해두거나 별도 폴더에 백업해 두세요!
3. 상황별 실전 명령어 가이드 🧮
이론을 알았으니 이제 실제 터미널에서 어떻게 입력해야 하는지 세부 시나리오별로 살펴보겠습니다.
📝 상황 1: 로컬에서 완전 초기화하기 (Reset의 3단계 옵션)
1) 작업 파일까지 몽땅 지우고 완전히 특정 커밋 시점으로 되돌리기:
git reset –hard [커밋해시ID]
2) 커밋 기록만 지우고, 변경된 파일은 Staging Area에 남기기 (재커밋 용도):
git reset –soft [커밋해시ID]
3) 기본값(Mixed) – 커밋과 스테이징을 풀고 일반 수정 파일로 보존하기:
git reset –mixed [커밋해시ID]
📝 상황 2: 이미 원격 저장소에 푸시한 경우 (안전한 Revert)
협업 중인 브랜치에서는 커밋 내역을 강제로 삭제하면 동료들의 로컬 브랜치와 충돌이 발생합니다. 이럴 때는 취소 커밋을 생성하세요.
git revert [취소할커밋해시ID]
여러 개의 연속된 커밋 범위를 역으로 취소하고 싶다면 git revert HEAD~3..HEAD 처럼 지정할 수도 있습니다.
🔢 내 상황에 맞는 Git 되돌리기 명령어 추천기
4. 실수로 날려도 살려내는 마법의 주문: git reflog 👩💻👨💻
만약 실수로 git reset –hard를 실행해서 필요한 코드까지 다 날려버렸다면 어떻게 해야 할까요? 절대 패닉에 빠지지 마세요. Git은 우리가 터미널에서 HEAD 포인터를 움직인 모든 발자국을 로컬 DB에 기록해 둡니다.
1. 터미널에
git reflog를 입력합니다.2. reset하기 직전의 커밋 번호(예:
HEAD@{1} 또는 해시코드)를 찾습니다.3.
git reset --hard HEAD@{1}을 입력하면 삭제되었던 커밋 상태가 기적처럼 완벽히 복원됩니다!
5. 실전 예시: 김 개발자의 야근 탈출 시나리오 📚
실제 실무에서 발생할 수 있는 구체적인 가상 사례를 통해 단계별 해결 흐름을 확인해 보겠습니다.
사례 주인공의 상황
- 상황: 금요일 오후 5시, 결제 모듈 리팩토링 중 3개의 커밋(A -> B -> C)을 연속으로 로컬에 생성함
- 문제 발생: 테스트 중 C 커밋뿐만 아니라 B 커밋의 설계 자체가 잘못되어, A 커밋(해시:
a1b2c3d) 상태로 완전히 롤백해야 함
해결 과정
1) 아직 원격(origin)에 푸시하지 않은 순수 로컬 커밋임을 확인: git status 체크
2) 미커밋된 잡다한 파일이 없는지 확인 후 완전 롤백 명령 실행: git reset --hard a1b2c3d
3) 로그 확인으로 A 시점으로 정확히 되돌아왔는지 검증: git log --oneline -n 3
최종 결과
– 결과 1: 커밋 B와 C로 인해 발생했던 버그 파일이 완전히 제거되고 깨끗한 상태 복구
– 결과 2: 별도의 충돌 해결이나 강제 푸시 없이 정시 퇴근 달성! 🎉
마무리: 핵심 내용 요약 📝
Git은 한 번 커밋한 내역을 웬만해서는 영구히 잃어버리지 않도록 튼튼하게 설계된 도구입니다. 원격 공유 여부와 작업 파일 보존 필요성에 맞춰 알맞은 도구를 선택해 보세요.
Git 되돌리기 핵심 공식 요약
자주 묻는 질문 ❓
git reflog를 통해 완전히 복구할 수 있습니다. 단, 커밋하지 않은 상태에서 날아간 작업 파일은 Git이 추적하지 못하므로 복구가 불가능합니다.git revert HEAD~3..HEAD 처럼 범위를 지정하거나, 커밋을 생성하지 않고 작업 파일만 되돌리는 git revert -n <커밋해시> 옵션을 여러 번 쓴 뒤 한 번에 커밋할 수 있습니다.git switch main(또는 본인 브랜치명)을 입력하면 됩니다.checkout 명령어가 브랜치 전환과 파일 복원이라는 너무 많은 역할을 겸하고 있어 혼란을 주었기 때문입니다. 최신 Git에서는 브랜치 이동은 git switch, 파일 복원은 git restore로 명확히 분리되었습니다.
Git으로 작업하다가 커밋이 꼬였을 때 더 이상 식은땀 흘리지 마시고, 내 브랜치 상태에 딱 맞는 안전한 명령어로 깔끔하게 복구해 보세요. 혹시 진행하시면서 해결되지 않는 에러 메시지가 있다면 편하게 댓글로 물어봐주세요~ 😊