rebase와 merge의 차이는 무엇인가요?

Question

Accepted Answer

**merge**와 **rebase** 모두 한 branch의 변경 사항을 다른 branch로 통합하지만 방식이 다릅니다. merge는 merge commit으로 **히스토리를 보존**하는 반면, rebase는 선형 시퀀스를 만들기 위해 **히스토리를 rewrite**합니다. 차이와 각각을 언제 사용할지 이해하는 것이 중요합니다.

## merge — 히스토리 보존(합침)

```text
main:     A───B───C───────M     ← M은 MERGE COMMIT(부모가 둘)
                  \       /
feature:           D───E
→ git merge feature: branch들을 합치는 M 생성
  ✓ 실제 히스토리 보존(branch가 존재했고 언제 merge되었는지 표시)
  ✗ 히스토리에 merge commit이 있음(merge가 많으면 어수선해 보일 수 있음)
```

## rebase — 선형 히스토리로 rewrite(재생)

```text
이전:  main: A───B───C    feature: A───B───D───E
feature를 main 위로 rebase한 후:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main(feature에서): feature의 commit(D,E)을 main의 최신(C) 위에 REPLAY
  ✓ 선형의 깔끔한 히스토리(merge commit 없음) — feature가 현재 main 위에 만들어진 것처럼
  ✗ commit을 REWRITE함(D→D', E→E'는 새 해시를 가진 새 commit)
```

rebase는 branch의 commit을 다른 branch의 끝에서 시작하도록 **이동**시켜 새 commit을 생성합니다. 깔끔한 선형 히스토리를 만듭니다.

## rebase의 황금률

```text
⚠️ push/공유된 commit(공개 히스토리)은 절대 rebase하지 말 것:
  → rebase는 commit을 rewrite(새 해시) → 다른 사람이 가진 것과 갈라짐
  → 협업자에게 심각한 혼란과 충돌을 일으킴
→ 로컬, push하지 않은 commit만 rebase. 공유/공개 branch 통합에는 merge.
```

## 각각을 언제 사용하나

```text
MERGE  → 공유 branch 통합; 실제 히스토리 보존; 기능을 main에 merge하는 팀 기본값
  (종종 pull request를 통해). 안전하고 비파괴적.
REBASE → 공유 전 로컬 commit 정리; feature branch를 main과 최신 상태로(선형) 유지;
  깔끔한 선형 히스토리 달성. 로컬/비공개 commit에만.
→ 일반 워크플로: 로컬에서 rebase로 정리한 다음 main에 merge(또는 PR).
```

## 왜 중요한가

rebase와 merge의 차이를 이해하는 것은 중요합니다. 둘 다 변경 사항을 통합하지만 히스토리에 근본적으로 다른 영향을 미치고, 올바르게(그리고 안전하게) 선택하는 것이 중요하므로, 흔히 논의되는 가치 있는 Git 지식입니다.

핵심 구분 — **merge는 히스토리를 보존**(branch가 합쳐졌음을 기록하는 merge commit을 생성하여 실제 개발 히스토리 유지)하는 반면 **rebase는 히스토리를 rewrite**(commit을 다른 branch의 끝으로 재생하여 작업이 최신 코드 위에서 이루어진 것처럼 깔끔한 선형 시퀀스 생성) — 은 프로젝트 히스토리가 어떤 모습이고 어떻게 읽히는지에 영향을 미칩니다.

트레이드오프(merge: 정확하지만 merge commit으로 어수선할 수 있음; rebase: 깔끔하고 선형이지만 commit을 rewrite함)를 이해하면 실제 히스토리를 중시할지 선형의 깔끔함을 중시할지에 따라 선택할 수 있습니다.

가장 중요하게는, **rebase의 황금률** — **push/공유된 commit은 절대 rebase하지 말 것** — 을 이해하는 것이 필수적입니다. rebase는 commit을 rewrite(새 해시 부여)하므로, 공유 히스토리를 rebase하면 협업자가 가진 것과 갈라져 심각한 혼란과 충돌을 일으키기 때문입니다. rebase는 로컬, push하지 않은 commit에만 안전합니다.

이 안전 규칙은 매우 중요하며, 위반 시 흔한 문제의 원천입니다.

**각각을 언제 사용할지**(공유 branch 통합과 히스토리 보존에는 merge, 종종 pull request를 통해 기능을 merge하는 팀 기본값; 공유 전 로컬 commit 정리나 feature branch를 선형으로 최신 상태로 유지하는 데는 rebase — 로컬 commit에만) 이해하는 것은 건전한 Git 관행을 반영합니다.

변경 사항 통합은 근본적이고 merge-vs-rebase 선택(히스토리와 안전 함의를 가진)은 빈번한 결정이자 면접 주제이므로, 그 차이 — 히스토리에 미치는 영향, 중요한 황금률, 각각을 언제 사용할지 — 를 이해하는 것은 깔끔한 히스토리를 안전하게 유지하는 데 중심이 되는 가치 있고 실무적으로 중요한 Git 지식이며, 모든 개발자가 파악해야 하는 흔히 논의되는 구분입니다.