개발을 하다 보면 로컬에서 작업한 내용을 원격 저장소(GitHub, GitLab 등)에 push까지 완료한 뒤에야 심각한 오류나 포함하지 말아야 할 파일이 들어간 것을 발견할 때가 있습니다. 로컬 커밋이라면 단순하게 수정하면 되지만, 이미 서버에 올라간 커밋은 다른 팀원들과 공유되고 있기 때문에 조심스러운 접근이 필요합니다. 오늘 포스팅에서는 이미 push한 commit 되돌리는 방법을 Reset과 Revert 두 가지 핵심 전략을 중심으로 완벽하게 정리해 보겠습니다.
목차
1. Git 복구의 양대 산맥: Reset vs Revert 차이점
2. Git Revert: 히스토리를 보존하며 안전하게 되돌리기
3. Git Reset: 커밋 기록을 깨끗하게 삭제하고 되감기
4. 혼자 하는 프로젝트 vs 협업 프로젝트에서의 대응 차이
5. 실전 단계별 해결법: 상황에 따른 명령어 가이드
6. 전문가들이 추천하는 Git 관리 도구와 예방 수칙
1. Git 복구의 양대 산맥: Reset vs Revert 차이점
잘못된 커밋을 되돌릴 때 가장 먼저 결정해야 하는 것은 “과거를 아예 지울 것인가(Reset)” 아니면 “잘못을 인정하고 반성하는 커밋을 새로 올릴 것인가(Revert)”입니다.
1-1. Reset의 개념
Reset은 시간을 뒤로 되감는 방식입니다. 특정 커밋 시점으로 헤드(HEAD)를 옮기고 그 이후의 커밋 기록은 아예 삭제하거나 로컬 작업 영역으로 되돌립니다. 기록 자체가 사라지기 때문에 커밋 히스토리가 매우 깔끔해지지만, 이미 공유된 원격 저장소에서는 큰 혼란을 야기할 수 있습니다.
1-2. Revert의 개념
Revert는 현재의 커밋 기록을 그대로 둔 채, 되돌리고 싶은 커밋의 내용을 정반대로 수행하는 새로운 커밋을 생성하는 방식입니다. 예를 들어 어떤 파일을 추가했다면, Revert 커밋은 그 파일을 삭제하는 작업을 수행합니다. 기록이 남기 때문에 안전하며 협업 시 가장 권장되는 방식입니다.
2. Git Revert: 히스토리를 보존하며 안전하게 되돌리기
협업 중인 프로젝트에서 이미 push한 commit 되돌리는 방법으로 가장 먼저 고려해야 할 것은 git revert입니다.
2-1. Revert의 동작 원리
git revert [커밋ID]를 실행하면, 해당 커밋에서 변경된 내용을 정확히 반대로 되돌리는 새로운 커밋이 만들어집니다. 이는 Git의 히스토리 선형성을 유지하면서도 문제를 해결할 수 있게 해줍니다. 팀원들이 이미 당신의 잘못된 커밋을 pull 받아갔더라도, Revert 커밋만 다시 push하면 자연스럽게 해결됩니다.
2-2. 여러 개의 커밋 되돌리기
가장 최근의 커밋 하나뿐만 아니라 여러 개를 한꺼번에 되돌려야 할 때도 있습니다. 이때는 범위를 지정하여 Revert를 수행할 수 있으며, 이 과정에서 발생하는 충돌(Conflict)은 일반적인 머지 과정처럼 해결한 뒤 커밋하면 됩니다. 기록을 남기는 것이 부끄러울 수 있지만, 대규모 프로젝트에서는 이 기록이 곧 소중한 자산이 됩니다.
3. Git Reset: 커밋 기록을 깨끗하게 삭제하고 되감기
기록 자체를 지워버리고 싶을 때 사용하는 강력한 도구입니다. 하지만 원격 저장소에 적용하려면 ‘강제 푸시’라는 위험한 과정이 동반됩니다.
3-1. Reset의 세 가지 모드
• Soft Reset: 커밋만 취소하고 작업했던 파일 내용은 그대로 유지합니다.
• Mixed Reset (기본값): 커밋을 취소하고 파일 내용은 남겨두지만, ‘스테이징’ 상태는 해제합니다.
• Hard Reset: 커밋, 스테이징, 작업 디렉토리의 파일 내용까지 모두 지정한 시점으로 완전히 되돌립니다. (주의: 복구가 불가능할 수 있음)
3-2. 원격 저장소 동기화 (Force Push)
로컬에서 Reset으로 커밋을 지운 뒤 다시 push를 시도하면, 원격 저장소와 로컬의 히스토리가 불일치하여 거절당합니다. 이때 git push origin [브랜치명] –force 명령을 사용해야 합니다. 이는 원격 저장소의 기록을 내 로컬 기록으로 덮어쓰는 행위이므로, 다른 팀원이 그 사이 작업을 올렸다면 모두 날아갈 수 있는 극도의 주의가 필요한 작업입니다.
4. 혼자 하는 프로젝트 vs 협업 프로젝트에서의 대응 차이
상황에 따라 어떤 방법을 선택할지 결정하는 기준은 ‘누가 이 코드를 보고 있는가’입니다.
4-1. 혼자 작업하는 개인 레포지토리
개인 프로젝트에서는 커밋 히스토리를 깔끔하게 유지하는 것이 중요할 수 있습니다. 따라서 잘못된 커밋을 Reset으로 지우고 강제 푸시를 해도 큰 문제가 없습니다. 오히려 지저분한 ‘Revert’ 기록 없이 완벽한 타임라인을 유지할 수 있다는 장점이 있습니다.
4-2. 여러 명이 함께하는 팀 프로젝트
절대적으로 Revert를 권장합니다. 내가 Reset 후 강제 푸시를 해버리면, 내 커밋을 기반으로 작업을 이어가던 동료들의 로컬 저장소는 엉망이 됩니다. 소위 ‘히스토리 꼬임’ 현상이 발생하여 팀 전체가 수시간 동안 복구 작업에 매달려야 할 수도 있습니다. 공개된 브랜치에서는 “기록을 삭제하지 않는다”는 것이 Git 협업의 철칙입니다.
5. 실전 단계별 해결법: 상황에 따른 명령어 가이드
실제 터미널에서 입력해야 할 명령어 순서를 정리해 드립니다.
5-1. 가장 안전하게 되돌리고 싶을 때 (Revert)
1. git log 명령어로 되돌릴 커밋의 해시값(예: abc1234)을 확인합니다.
2. git revert abc1234 명령어를 실행합니다.
3. 에디터가 뜨면 커밋 메시지를 확인하고 저장합니다.
4. git push origin [브랜치명]을 통해 원격에 반영합니다.
5-2. 히스토리를 완전히 지우고 싶을 때 (Reset – 개인용)
1. git reset –hard HEAD~1 (직전 커밋 한 개를 완전히 삭제)
2. git push origin [브랜치명] –force (원격 저장소 강제 업데이트)
참고: HEAD~1 대신 특정 커밋 해시값을 넣으면 그 시점으로 점프합니다.
6. 전문가들이 추천하는 Git 관리 도구와 예방 수칙
숙련된 개발자들은 실수를 줄이기 위해 도구의 도움을 받습니다.
6-1. GUI 도구 활용 (Sourcetree, GitKraken)
명령어 라인이 헷갈린다면 시각적인 도움을 주는 GUI 도구를 사용하세요. 현재 브랜치 상태와 커밋 히스토리를 한눈에 볼 수 있어 Reset 시점이 어디인지, Revert 결과가 어떻게 나올지 미리 예측하기 쉽습니다.
6-2. 커밋 전 점검 습관
이미 push한 commit 되돌리는 방법보다 중요한 것은 push 전에 실수를 막는 것입니다. git diff –staged를 통해 올리기 직전의 코드를 다시 한번 검토하거나, pre-push hook을 설정하여 특정 키워드(예: TODO, 테스트용 코드)가 포함된 경우 push가 되지 않도록 방어 로직을 구축하는 것을 추천합니다.
결론: 요약 및 복구 전략
• 이미 push한 commit 되돌리는 방법 중 가장 권장되는 것은 기록을 보존하는 Revert입니다.
• 혼자만의 공간에서 히스토리를 관리하고 싶다면 Reset 후 강제 푸시를 사용하세요.
• 협업 시 강제 푸시는 팀원과의 신뢰를 깨뜨릴 수 있으므로 반드시 사전에 합의해야 합니다.
Git은 실수를 바로잡을 수 있는 강력한 기능을 제공합니다. 당황하지 말고 상황에 맞는 도구를 선택하여 안전하게 코드를 관리하시기 바랍니다.
답글 남기기