Git Merge vs Rebase - 언제 쓰고, 무슨 차이일까?

Git Merge vs Rebase — 같은 목표, 다른 철학

두 명령어의 차이를 이해하면 팀의 Git 히스토리가 달라집니다.

---

1. 둘 다 "브랜치를 합친다"

merge와 rebase는 모두 한 브랜치의 변경 사항을 다른 브랜치에 통합하기 위한 명령어다. 목적은 동일하지만, 히스토리를 만들어가는 방식이 근본적으로 다르다.

• Merge — 두 브랜치가 합쳐졌다는 기록 자체를 남긴다.
• Rebase — 커밋들을 다른 브랜치의 끝에 마치 처음부터 거기서 작업한 것처럼 재작성한다.

---

2. 히스토리 구조 비교

git merge

A --- B --- C ----------- M   ← main (M = merge commit)
             \           /
              F1 --- F2       ← feature

두 브랜치의 분기와 합류가 그대로 기록된다. M은 두 브랜치를 합쳤다는 merge commit이다.

git rebase

A --- B --- C --- F1' --- F2'   ← feature (rebased onto main)

feature 브랜치의 커밋들이 main 끝으로 이동한다. F1, F2는 내용은 같지만 커밋 해시가 새로 생성되어 F1', F2'가 된다.

---

3. 핵심 차이 정리

항목	Merge	Rebase
히스토리 형태	비선형 (브랜치 구조 보존)	선형 (일직선)
Merge commit	생성됨	생성 안 됨
기존 커밋 해시	변경 없음	모두 새로 생성
작업 이력 투명성	언제 어디서 합쳤는지 명확	깔끔하지만 원래 흐름은 사라짐
공유 브랜치 사용	안전	위험 (팀원 충돌 유발)

---

4. 실제 명령어

Merge

git checkout main
git merge feature/login

# 빠른 합류가 가능해도 merge commit을 강제로 생성
git merge --no-ff feature/login

Rebase

git checkout feature/login
git rebase main

# 충돌 해결 후 계속 진행
git rebase --continue

# rebase 중단하고 원래 상태로 복구
git rebase --abort

⚠️ 주의 — 이미 원격(origin)에 push한 브랜치, 특히 다른 사람이 기반으로 삼고 있는 브랜치에는 절대 rebase하지 말 것. 커밋 해시가 바뀌어 팀원 모두에게 충돌이 발생한다.

---

5. 언제 무엇을 써야 할까

Merge를 쓸 때

• feature 브랜치를 main / develop에 통합할 때 (PR 머지)
• 여러 사람이 같은 브랜치를 공유하는 협업 환경
• 언제 어떤 기능이 합쳐졌는지 이력을 명확히 남겨야 할 때
• hotfix 브랜치를 main과 develop 양쪽에 반영할 때

Rebase를 쓸 때

• 내 로컬 feature 브랜치를 최신 main으로 업데이트할 때
• PR 올리기 전에 커밋 히스토리를 깔끔하게 정리하고 싶을 때
• 혼자 작업하는 브랜치에서 불필요한 merge commit을 없애고 싶을 때
• git rebase -i로 커밋을 squash·수정할 때

---

6. Interactive Rebase — 커밋 다듬기

Rebase의 강력한 활용법 중 하나가 Interactive Rebase다. PR 올리기 전에 지저분한 커밋들을 하나로 합치거나 메시지를 수정할 때 유용하다.

# 최근 3개 커밋을 대화형으로 수정
git rebase -i HEAD~3

에디터가 열리면 각 커밋 앞의 pick을 원하는 명령어로 바꾼다.

pick  a1b2c3  feat: 로그인 UI 추가
s     d4e5f6  fix: 버튼 색상 수정    ← squash: 위 커밋에 합치기
s     g7h8i9  fix: 오타 수정         ← squash: 위 커밋에 합치기

주요 명령어는 다음과 같다.

명령어	약자	동작
pick	p	커밋 그대로 유지
reword	r	커밋 메시지 수정
squash	s	이전 커밋에 합치기 (메시지 편집 가능)
fixup	f	이전 커밋에 합치기 (메시지 버림)
drop	d	커밋 삭제

---

7. 실전 권장 워크플로우

많은 팀들이 두 명령어를 상황에 따라 혼용한다. 일반적으로 검증된 패턴은 다음과 같다.

# 1. 개발 시작 — main의 최신 내용을 내 브랜치에 반영
git checkout feature/my-feature
git fetch origin
git rebase origin/main        # ← 로컬 브랜치이므로 rebase 안전

# 2. 개발 완료 — PR 전에 커밋 정리
git rebase -i origin/main     # ← squash로 커밋 정돈

# 3. PR 승인 후 — main에 합치기
git checkout main
git merge --no-ff feature/my-feature   # ← merge commit으로 이력 보존
git push origin main

💡 요약 — 개발 중에는 rebase로 히스토리를 깔끔하게 유지하고, 완성된 기능을 main에 합칠 때는 merge로 이력을 남긴다.

---

8. 한 줄 정리

• Merge — "우리가 이 시점에 합쳤다"는 사실을 기록으로 남기고 싶을 때
• Rebase — "처음부터 이렇게 깔끔하게 작업했다"고 히스토리를 정돈하고 싶을 때