Git rebase vs merge: 브랜치 통합 방법 상세 비교 및 활용 가이드

Git rebase vs merge: 브랜치 통합 방법 상세 비교 및 활용 가이드

Git에서 여러 브랜치의 변경 사항을 하나로 통합하는 두 가지 주요 방법인 rebase와 merge는 각각의 특징과 장단점을 가지고 있습니다. 어떤 방법을 선택하느냐에 따라 커밋 히스토리의 형태가 달라지므로, 프로젝트의 특성과 협업 방식에 맞춰 신중하게 결정해야 합니다.

1. merge (병합)

merge는 가장 일반적이고 직관적인 브랜치 통합 방법입니다. 두 브랜치의 최근 커밋들을 포함하는 새로운 'merge commit'을 생성하여 두 브랜치의 작업 내역을 하나로 합칩니다.

• 개념: 현재 브랜치(예: main)에 다른 브랜치(예: feature)의 커밋들을 가져와 합치는 방식. 이때, 두 브랜치의 히스토리를 그대로 유지하면서 두 히스토리가 만나는 지점에 새로운 merge commit이 생깁니다.
• 언제/왜 쓰는가:
  • 기존 브랜치의 히스토리를 그대로 보존하고 싶을 때
  • 어떤 브랜치들이 언제 병합되었는지 명확한 기록을 남기고 싶을 때
  • 협업 시, 다른 팀원의 작업 내역을 그대로 추적해야 할 때
  • 안정적인 배포 브랜치(main, develop 등)에 feature 브랜치를 통합할 때
• 사용법:
  1. 통합받을 브랜치(예: main)로 이동합니다: git checkout main
  2. 병합할 브랜치(예: feature)의 변경사항을 현재 브랜치로 가져옵니다: git merge feature
  3. 충돌이 발생하면, 충돌을 해결하고 스테이징한 후 커밋합니다: git add . -> git commit
• 장점:
  • 히스토리를 변경하지 않아 안전합니다.
  • 어떤 브랜치가 언제 통합되었는지 명확한 기록이 남습니다.
• 단점:
  • 많은 수의 브랜치가 빈번하게 merge될 경우, 커밋 히스토리가 복잡해지고 로그를 읽기 어려워질 수 있습니다 (브랜치 히스토리가 점처럼 많이 찍힘).

2. rebase (리베이스)

rebase는 현재 브랜치의 기반(base)이 되는 커밋을 다른 브랜치의 최신 커밋으로 옮기는 방식입니다. 즉, 현재 브랜치의 커밋들을 잠시 떼어내서, 목표 브랜치(예: main)의 최신 커밋 위에 다시 적용하는 것입니다.

• 개념: 현재 브랜치의 커밋들을 떼어내어, 다른 브랜치의 최신 커밋 위에 '재배치(re-base)'하는 방식. 결과적으로 선형적(linear)이고 깔끔한 커밋 히스토리를 만듭니다.
• 언제/왜 쓰는가:
  • 자신의 feature 브랜치가 오래되어 main 브랜치의 최신 변경 사항을 반영하고 싶을 때
  • 커밋 히스토리를 깔끔하고 선형적으로 유지하고 싶을 때
  • 공유되지 않은(아직 push하지 않은) 브랜치의 히스토리를 정리하고 싶을 때
  • merge commit을 최소화하고 싶을 때
• 사용법:
  1. 기준이 될 브랜치(예: main)의 최신 상태를 가져옵니다: git fetch origin main
  2. feature 브랜치로 이동합니다: git checkout feature
  3. main 브랜치의 최신 커밋 위로 feature 브랜치를 재배치합니다: git rebase origin/main (또는 git rebase main)
  4. 충돌이 발생하면, 충돌을 해결하고 git add . 후 git rebase --continue를 실행합니다.
  5. rebase 완료 후, main 브랜치로 이동하여 feature 브랜치를 fast-forward merge 합니다: git checkout main -> git merge feature
• 장점:
  • 커밋 히스토리가 선형적이 되어 매우 깔끔하고 이해하기 쉽습니다.
  • 불필요한 merge commit이 생기지 않습니다.
• 단점:
  • 원본 커밋의 commit hash가 변경됩니다. 이미 원격 저장소에 push하여 다른 사람과 공유한 브랜치에 rebase를 적용하면 히스토리 충돌을 일으킬 수 있으므로 매우 주의해야 합니다.
  • 충돌 해결 과정이 merge보다 복잡하게 느껴질 수 있습니다.

3. rebase vs merge 비교

구분	merge	rebase
커밋 히스토리	브랜치 히스토리 유지, merge commit 생성	선형적, 깔끔함. 커밋 해시 변경.
안정성	높음 (원본 히스토리 변경 없음)	공유된 브랜치에서는 위험 (히스토리 변경)
협업	히스토리 추적 용이	공유되지 않은 브랜치 정리 시 유용
복잡성	간단	충돌 해결 시 복잡할 수 있음
주요 용도	메인 브랜치에 기능 브랜치 통합, 기록 보존	개인 브랜치 최신화, 히스토리 깔끔하게 유지

4. 언제 어떤 것을 사용할까?

• 팀원들과 공유하는 브랜치 (예: main, develop): merge를 사용하는 것이 안전하고 권장됩니다. 히스토리를 보존하고 병합 시점을 명확히 기록하기 위함입니다.
• 개인 작업 브랜치 (예: feature/my-new-feature): main 브랜치의 최신 변경 사항을 반영하여 자신의 브랜치를 최신 상태로 유지하고 싶을 때 rebase를 사용할 수 있습니다. 이렇게 하면 나중에 main 브랜치로 병합할 때 fast-forward merge가 되어 히스토리가 더욱 깔끔해집니다.
• 주의: 절대 이미 원격 저장소에 push하여 다른 사람들과 공유하고 있는 브랜치에 rebase를 사용하지 마세요. 이는 다른 팀원들에게 심각한 히스토리 충돌을 야기할 수 있습니다.

rebase는 강력하지만 양날의 검과 같습니다. 커밋 히스토리를 깔끔하게 유지하는 데 큰 도움이 되지만, 사용법을 정확히 숙지하고 공유되지 않은 브랜치에만 사용하는 원칙을 지키는 것이 중요합니다.