Git rebase vs merge — 팀마다 답이 다른 진짜 이유

## 질문 하나로 팀 문화가 드러난다

"우리 팀은 rebase 써요, merge 써요?"

이 질문에 대한 답은 그 팀의 **코드 역사에 대한 철학**을 드러낸다. merge가 옳고 rebase가 그르거나, 반대가 아니다. 두 접근은 다른 가치를 추구한다.

## merge: 있었던 일을 그대로

```
A---B---C  (main)
     \
      D---E  (feature)

git merge feature:
A---B---C---F  (F는 merge commit)
         \ /
          D---E
```

merge는 히스토리를 보존한다. "feature 브랜치가 언제 시작됐고, 언제 메인에 합류했는지"가 그래프에 그대로 남는다. 충돌도 한 번만 처리하면 된다.

단점은 그래프가 복잡해진다는 점이다. 장기 운영 저장소에서 여러 브랜치가 교차하면 git log --graph가 스파게티가 된다.

## rebase: 없었던 것처럼 다시 쓴다

```
A---B---C  (main)
         \
          D'---E'  (feature, rebased)

git rebase main:
A---B---C---D'---E'
```

rebase는 feature 브랜치의 커밋들을 main의 최신 커밋 위에 재생성한다. D와 E는 같은 변경사항이지만 새 SHA를 가진 D', E'가 된다. 히스토리가 직선으로 정리되어 `git log`가 읽기 쉬워진다.

## 황금 규칙: 공유 브랜치를 rebase하지 마라

```bash
# 절대 하면 안 되는 것
git checkout main
git rebase feature  # main은 다른 사람이 사용 중
git push --force
```

rebase는 커밋 SHA를 바꾼다. 같은 브랜치를 다른 사람이 로컬에 체크아웃하고 있으면, 그 사람의 히스토리와 원격 히스토리가 갈라져서 혼란이 생긴다. **rebase는 로컬에서, 혼자 작업하는 브랜치에서만** 한다.

## 팀 규칙 제안

**merge를 선택하는 팀:**
- 오픈소스 프로젝트 (기여 히스토리 중요)
- 여러 릴리즈 브랜치 병렬 유지
- "언제 누가 무엇을 합쳤는가"가 감사(audit)에 중요할 때

**rebase를 선택하는 팀:**
- 소규모 팀, 기능 브랜치가 단명
- 깔끔한 main 히스토리가 코드 리뷰에 중요
- PR 전 로컬 커밋 정리(squash + rebase)가 관행인 곳

## interactive rebase — 실전 도구

```bash
git rebase -i HEAD~3
```

지난 3개 커밋을 편집할 수 있다. WIP 커밋들을 squash하거나, 커밋 메시지를 reword하거나, 순서를 바꿀 수 있다. PR 올리기 전 정리에 유용하다.

```
pick a1b2c3 WIP: trying approach A
squash d4e5f6 WIP: actually approach B
reword g7h8i9 add feature X with retry logic
```

## 결론

rebase는 "히스토리는 읽히기 좋아야 한다"는 관점, merge는 "히스토리는 있었던 일 그대로여야 한다"는 관점이다. 팀의 가치관과 배포 방식에 맞게 선택하면 된다. 하나만 옳다는 주장은 대부분 개인 취향을 일반화한 것이다.