"팀장님, 이번 기능 브랜치 Merge(병합) 했습니다!" 자신 있게 말했지만, git log를 본 팀장님의 표정이 미묘합니다. 다른 팀원들의 작업 내역과 내 작업 내역이 뒤섞이고, 의미 없는 Merge branch '...' 커밋들이 중간중간 끼어들어, 전체 히스토리가 스파게티처럼 얽혀버렸기 때문이죠. 🍝
이런 지저분한 Git 히스토리를 깔끔하게 '다림질'해서, 마치 한 사람이 순서대로 작업한 것처럼 아름답게 만들 수 있는 강력한 마법이 있습니다. 바로 git rebase 입니다.
Merge vs. Rebase: 역사를 기록하는 두 가지 방식
main 브랜치에서 새로운 기능 개발을 위해 feature 브랜치를 만들었다고 상상해 봅시다. 그동안 다른 팀원들이 main 브랜치에 새로운 커밋들을 추가했습니다. 이제 내 작업을 main에 합쳐야 합니다.
- Merge (병합): "모든 역사를 그대로, 합치기만 할게" 가장 일반적인 방식입니다. main 브랜치의 최신 변경 사항과 내 feature 브랜치의 변경 사항을 합쳐, Merge commit 이라는 새로운 '접합점' 커밋을 만듭니다. 있는 그대로의 역사를 모두 보존하는 정직한 방법이지만, 여러 명이 동시에 작업하면 히스토리 그래프가 매우 복잡해집니다.
- Rebase (재배치): "네 역사를 최신 역사 위에, 새로 쌓아줄게" rebase는 말 그대로 베이스(Base)를 재배치(Re-base) 한다는 뜻입니다. 내 feature 브랜치가 시작되었던 옛날 main의 커밋 지점을, 현재 main의 가장 최신 커밋 지점으로 옮겨줍니다. 그 뒤에 내 feature 브랜치의 커밋들을 하나씩 차곡차곡 다시 쌓아 올리죠.
- 결과적으로, Merge commit 없이 아주 깔끔하고 선형적인(Linear) 히스토리가 만들어집니다. 마치 내가 처음부터 main의 가장 최신 버전에서 작업을 시작한 것처럼 역사가 '재구성'되는 것입니다.
Rebase의 백미: 대화형 Rebase (rebase -i)
rebase의 진정한 힘은 과거의 커밋들을 자유자재로 수정할 수 있는 대화형(Interactive) rebase에서 나옵니다. git rebase -i [기준 커밋] 명령어를 사용하면, 텍스트 편집기가 열리면서 내가 쌓아온 커밋 목록을 보여줍니다. 여기서 우리는 타임머신을 탄 것처럼 과거를 조작할 수 있습니다.
상황: 자잘하게 남긴 5개의 커밋이 지저분해 보여, 하나로 합치고 메시지도 수정하고 싶다.
- 명령어 실행: git rebase -i HEAD~5 (최근 5개의 커밋을 수정하겠다)
- 편집기 화면: 다음과 같은 화면이 나타납니다.
-
pick f7f3f6d Feat: Add user login form pick 310154e Fix: Correct login button CSS pick a5f4a0d Feat: Implement password validation pick 1b6d5df Docs: Update login API docs pick 0d27025 Fix: Minor typo in error message # Commands: # p, pick <commit> = use commit # s, squash <commit> = use commit, but meld into previous commit # ... (다른 여러 명령어들) ... - 명령 수정: pick을 원하는 명령으로 수정합니다. 맨 위 커밋을 기준으로 나머지 4개를 합치고(squash) 싶다면, 아래처럼 수정하고 저장합니다.
-
pick f7f3f6d Feat: Add user login form s 310154e Fix: Correct login button CSS s a5f4a0d Feat: Implement password validation s 1b6d5df Docs: Update login API docs s 0d27025 Fix: Minor typo in error message - 커밋 메시지 재작성: 저장하면, 5개 커밋의 메시지를 하나로 합칠 수 있는 편집기 화면이 다시 열립니다. 여기서 깔끔하게 최종 커밋 메시지를 작성하고 저장하면...
- 완료: 지저분했던 5개의 커밋이, 하나의 완벽한 커밋으로 재탄생합니다! 🎉
이 외에도 커밋 순서를 바꾸거나(drag and drop), 특정 커밋을 삭제하거나(drop), 메시지를 수정(reword)하는 등 다양한 '역사 개조'가 가능합니다.
경고: 절대 공용 브랜치에서는 Rebase 하지 마세요!
rebase는 매우 강력하지만, 절대적인 규칙이 하나 있습니다. 다른 팀원과 함께 사용하는 공용 브랜치(e.g., main, develop)에서는 절대 rebase를 사용하면 안 됩니다.
rebase는 기존의 커밋을 지우고 새로운 커밋을 만드는 방식으로 역사를 '재작성'합니다. 만약 다른 사람이 이미 받아 간(pull) 공용 히스토리를 당신이 rebase로 바꿔버리면, 그 사람의 로컬 저장소와 원격 저장소의 역사가 완전히 꼬여버리는 대재앙이 발생합니다.
Rebase는 항상 나 혼자 작업하는 로컬 브랜치에서, main에 합치기(merge) 전에 히스토리를 깔끔하게 정리하는 용도로만 사용하세요.
마치며
git merge 가 팀의 모든 활동을 정직하게 기록하는 '회의록'이라면, git rebase 는 최종 보고서를 제출하기 전에 초고를 깔끔하게 다듬고 정리하는 '퇴고' 과정과 같습니다.
rebase를 올바르게 사용하면, 동료들이 훨씬 이해하기 쉬운 깨끗한 프로젝트 히스토리를 만들 수 있습니다. 이는 곧 더 나은 협업과 유지보수 효율로 이어지죠. Git을 그저 '백업 도구'가 아닌, '프로젝트의 역사를 기록하는 역사가'의 관점에서 다루고 싶다면, rebase는 당신이 연마해야 할 최고의 기술이 될 것입니다. ✨