Git Rebase vs Merge: 개념, 차이점 및 선택 가이드

Git Rebase와 Merge: 개념, 차이점 및 선택 가이드

Git에서 브랜치 통합은 주로 merge와 rebase라는 두 가지 방식으로 이루어집니다. 각 방식은 히스토리의 형태와 프로젝트의 흐름에 영향을 미치므로, 어떤 상황에서 어떤 방식을 사용하는 것이 더 효과적인지 이해하는 것이 중요합니다.

1. Git Merge

개념: git merge는 두 개 이상의 브랜치의 변경 사항을 하나로 통합하는 가장 일반적인 방법입니다. 기본적으로 두 브랜치의 공통 조상 커밋을 찾고, 각 브랜치의 최신 커밋을 포함하는 새로운 '병합 커밋(merge commit)'을 생성합니다.

특징:

• 히스토리 보존: 기존 브랜치의 커밋 히스토리를 그대로 유지하며, 어떤 브랜치가 언제 병합되었는지 명확하게 보여주는 새로운 커밋이 추가됩니다.
• 선형적이지 않은 히스토리: 여러 브랜치가 활발하게 사용되고 자주 병합될 경우, 히스토리가 복잡해지고 나뭇가지처럼 얽힌 형태가 될 수 있습니다.
• 안전성: 기존 커밋을 변경하지 않으므로 원본 히스토리를 그대로 보존하며, 실수로 인한 데이터 손실 위험이 적습니다.

사용 시나리오:

• 기능 개발 완료 후 메인 브랜치(main, develop 등)에 통합할 때: 기능 브랜치의 모든 커밋을 유지하면서 메인 브랜치에 합치고 싶을 때 사용합니다.
• 협업 환경에서 공유 브랜치로 통합할 때: 다른 팀원들이 작업한 내용을 히스토리상 명확히 구분하여 통합하고 싶을 때 유용합니다.
• 히스토리의 정확한 기록이 중요할 때: 언제 어떤 변경이 발생했는지, 어떤 브랜치에서 왔는지 추적하는 것이 중요할 때 사용합니다.

기본 사용법:

1. 통합될 브랜치(예: main)로 이동합니다.

   git checkout main
   

2. 통합할 브랜치(예: feature/my-new-feature)를 현재 브랜치로 병합합니다.

   git merge feature/my-new-feature
   

3. 병합 커밋 메시지를 작성하고 저장합니다 (충돌 발생 시 해결 후).

2. Git Rebase

개념: git rebase는 특정 브랜치의 커밋들을 다른 브랜치의 최신 커밋 위에 '재배치(re-apply)'하는 방식입니다. 원래 브랜치의 커밋들을 순서대로 하나씩 새로운 베이스 커밋 위에 다시 적용하여, 마치 처음부터 최신 커밋을 기반으로 작업한 것처럼 선형적인 히스토리를 만듭니다.

특징:

• 선형적인 히스토리: 모든 커밋이 일렬로 정렬되어 히스토리가 매우 깔끔하고 이해하기 쉬워집니다.
• 히스토리 변경: 새로운 커밋을 생성하는 것이 아니라, 기존 커밋의 내용을 기반으로 새로운 커밋을 생성하므로 원본 커밋은 변경되거나 사라집니다 (주로 main 브랜치의 변경사항을 rebase 할 때).
• 주의 필요: 이미 공유된 브랜치(public branch)에 rebase를 사용하면 히스토리가 재작성되어 다른 팀원에게 혼란을 줄 수 있습니다. 절대 푸시된(pushed) 브랜치에는 rebase를 사용하지 않는 것이 좋습니다.

사용 시나리오:

• 개인 작업 브랜치를 최신 상태로 유지할 때: main 또는 develop 브랜치에 새로운 커밋이 생겼을 때, 이를 자신의 기능 브랜치에 적용하여 최신 상태를 반영하고 싶을 때 사용합니다.
• 커밋 히스토리를 깔끔하게 정리하고 싶을 때: 여러 개의 작은 커밋들을 하나로 합치거나(squash), 순서를 바꾸거나, 메시지를 수정하여 최종 커밋 히스토리를 간결하게 만들고 싶을 때(git rebase -i 사용).
• 최종 병합 시 깔끔한 히스토리를 원할 때: rebase를 통해 자신의 기능 브랜치를 최신 main 브랜치 위에 올려놓은 후, main 브랜치로 fast-forward merge를 수행하여 선형적인 히스토리를 유지하고 싶을 때.

**기본 사용법 (기능 브랜치에 메인 브랜치 업데이트 적용): **

1. 최신 상태로 업데이트할 기능 브랜치(예: feature/my-new-feature)로 이동합니다.

   git checkout feature/my-new-feature
   

2. 메인 브랜치(예: main)를 현재 브랜치 위에 재배치합니다.

   git rebase main
   

3. 충돌이 발생하면 해결하고 git add . 후 git rebase --continue를 실행합니다.
4. 충돌이 없거나 해결된 후, 이제 feature/my-new-feature 브랜치는 main 브랜치의 최신 커밋 위에 위치하게 됩니다.

3. Rebase vs Merge: 언제 무엇을 사용할까?

기준	Git Merge	Git Rebase
히스토리	선형적이지 않음, 병합 커밋으로 통합 기록 명확	선형적, 깔끔함, 커밋이 재배치되어 원본 커밋 내용 기반으로 새 커밋 생성
커밋 변경	기존 커밋을 변경하지 않음	기존 커밋을 변경/재생성함 (새로운 커밋 ID 부여)
안전성	높음 (원본 히스토리 보존)	낮음 (공유된 브랜치에 사용 시 주의 필요)
협업 환경	공유 브랜치 간 통합에 안전하고 기록이 명확함	푸시된(pushed) 브랜치에는 절대 사용 금지
개인 작업 브랜치	최신 main 브랜치를 가져오기 위해 병합 가능	최신 main 브랜치를 가져와 자신의 브랜치를 최신 상태로 유지하기에 좋음
최종 통합	병합 커밋 생성	(옵션) 개인 브랜치를 최신 main 위로 rebase 후 main으로 fast-forward merge

권장 사항:

• 개인 작업 브랜치: 다른 사람과 공유하지 않는 개인 작업 브랜치에서는 rebase를 사용하여 히스토리를 깔끔하게 유지하고 최신 main 브랜치 내용을 쉽게 반영할 수 있습니다.
• 공유 브랜치(main, develop, master 등): 팀원들과 공유하는 메인 브랜치에는 merge를 사용하여 명확한 통합 기록을 남기는 것이 안전합니다. rebase를 main 브랜치에 직접 적용하는 것은 피해야 합니다.
• 협업 시: 다른 사람의 작업 내용이 포함된 브랜치를 자신의 브랜치에 가져올 때는 merge를 사용하는 것이 일반적입니다. 자신의 브랜치를 최신 상태로 만들고 싶을 때 rebase를 사용할 수 있으나, 반드시 git pull --rebase 옵션을 사용하거나 rebase 후 push 시 force-with-lease를 사용해야 합니다.

rebase는 강력하지만 히스토리를 변경하는 위험이 따르므로, 각 방식의 특징을 잘 이해하고 상황에 맞게 신중하게 사용하는 것이 Git 브랜치 관리의 핵심입니다.