Git Rebase와 Squash를 활용한 커밋 히스토리 클린징
[Troubleshooting] Git Rebase와 Squash를 활용한 커밋 히스토리 클린징
"팀원들과 협업하여 프로젝트를 진행하다 보면, 기능을 개발하는 과정에서 남긴 '오타 수정', '임시 테스트', '진짜 최종' 같은 부끄러운 커밋들이 수십 개씩 쌓여 전체 Git 히스토리를 더럽히곤 합니다."
버전 관리의 핵심은 코드의 변경 이력을 누구나 이해하기 쉽게 기록하는 데 있습니다. 하지만 수많은 파편적 커밋 로그가 마스터 브랜치에 그대로 병합되면, 나중에 장애가 발생했을 때 원인(Git Bisect 등)을 추적하는 작업이 지옥처럼 변하게 됩니다.
무분별하게 쌓인 커밋을 하나로 합치고 히스토리를 일직선으로 정돈하는 것은 시니어 개발자의 필수 덕목입니다. 본 가이드에서는 git rebase -i(Interactive Rebase)와 Squash 기능을 활용해 커밋 로그를 예술적으로 다듬는 실무 트러블슈팅 가이드를 제공합니다.
📌 이 글의 핵심 포인트
- Merge vs Rebase: 불필요한 Merge 커밋을 없애고 선형적인(Linear) 히스토리를 유지하는 이유
- Interactive Rebase:
git rebase -i명령어를 이용한 커밋 편집 및 압축(Squash) 원리- 안전 수칙: 이미 원격 저장소에 푸시된 브랜치를 다룰 때 주의해야 할 치명적 실수 방지법
1단계: 지저분한 커밋 로그가 가져오는 부작용
기능 하나를 개발하는 동안 git commit -m "작업중"을 반복하다 보면 원격 저장소의 그래프가 복잡하게 얽히게 됩니다. 이 상태에서 기본 git merge를 수행하면 불필요한 분기 병합 커밋까지 생성되어 코드 리뷰어의 눈살을 찌푸리게 만듭니다.
코드의 가독성뿐만 아니라 유지보수 관점에서 각 커밋은 '하나의 완결된 단위의 작업'이어야 합니다. 따라서 PR(Pull Request)을 날리기 전, 내 로컬 브랜치에 쌓인 지저분한 커밋들을 논리적인 단위로 압축하는 과정이 반드시 필요합니다.
2단계: Interactive Rebase를 통한 Squash 실행 방법
최근 5개의 커밋을 하나로 묶고 싶다면 터미널에 대화형 리베이스 명령어를 입력합니다. 에디터 창이 열리면서 최근 커밋 목록이 나타나는데, 여기서 합치고 싶은 커밋들의 앞글자를 pick에서 squash(또는 s)로 변경해 주면 됩니다.
# 최근 5개의 커밋 내역을 대상으로 대화형 리베이스 시작
git rebase -i HEAD~5
# 에디터 창 설정 예시:
# pick a1b2c3d 로그인 UI 구현
# squash e4f8a9b 오타 수정
# squash 7c8d9e0 API 연동 임시 테스트
```위와 같이 설정하고 저장하면, Git은 5개의 커밋을 하나로 뭉쳐주면서 새로운 통합 커밋 메시지를 작성할 수 있는 창을 띄워줍니다. 이 과정을 거치면 수많은 잡다한 로그가 하나의 깔끔한 의미 있는 커밋으로 재탄생합니다.
🙋♂️ 자주 묻는 질문 (FAQ)
Q. 이미 원격 저장소(GitHub)에 푸시한 커밋도 Rebase해도 되나요?
A. 혼자서만 사용하는 개인 브랜치라면 git push --force-with-lease로 덮어씌워도 무방하지만, 여러 명이 공유하는 메인 브랜치에서는 절대 히스토리를 조작하면 안 됩니다.
Q. 리베이스 도중 충돌(Conflict)이 나면 어떻게 수습하나요?
A. 충돌 난 파일을 수정 후 git add .를 한 뒤 git rebase --continue를 입력하면 중단된 지점부터 리베이스가 다시 진행됩니다. 포기하고 싶다면 git rebase --abort로 언제든 안전하게 원상복구할 수 있습니다.
💡 핵심 정리 및 마무리
깔끔하게 정돈된 Git 히스토리는 팀원과의 소통을 원활하게 만들고 프로젝트의 신뢰도를 높여줍니다. Squash와 Rebase를 적극 활용해 군더더기 없는 프로페셔널한 버전 관리 습관을 만들어 보시기 바랍니다.
댓글
댓글 쓰기