Git Rebase vs Merge — 실무에서 언제 뭘 쓰는지 정리했다

# Git Rebase vs Merge — 실무에서 언제 뭘 쓰는지 정리했다

"rebase 쓰면 히스토리 깔끔해진다"는 말은 맞습니다. 하지만 상황을 안 가리고 쓰면 팀에서 욕을 먹습니다.

## 핵심 차이를 한 줄로

**merge**: 두 브랜치의 분기 내역을 보존하며 병합. 히스토리에 "언제 갈라졌고 언제 합쳐졌는지"가 남음.
**rebase**: 현재 브랜치의 커밋을 대상 브랜치 끝에 다시 쌓음. 히스토리가 선형이 됨. 커밋 해시가 변경됨.

## 언제 rebase를 써야 하나

**로컬 feature 브랜치 정리**: main이 앞서 나갔을 때, 로컬 feature를 최신 main 위로 옮기기. 아직 push하지 않은 커밋이라면 rebase가 맞습니다.

```bash
# main 최신화 후 feature를 main 위로 rebase
git checkout feature/my-work
git rebase main
```

**커밋 정리 (interactive rebase)**: 개발 중 "wip", "fix typo", "fix again" 등 의미 없는 커밋들을 PR 전에 squash하거나 reword.

```bash
# 최근 4개 커밋 정리
git rebase -i HEAD~4
```

## 언제 merge를 써야 하나

**공유 브랜치 병합**: main, develop 등 팀이 함께 쓰는 브랜치에는 merge를 써야 합니다. rebase하면 팀원의 로컬 히스토리와 충돌합니다.

**릴리스 추적이 필요할 때**: "언제 어떤 feature가 포함됐는지"를 보려면 merge commit이 필요합니다. GitHub의 merge PR 방식이 이 패턴입니다.

## 황금률: 절대 하지 말아야 하는 것

**이미 push된 공유 브랜치를 rebase하지 말 것.**

push된 커밋을 rebase하면 커밋 해시가 바뀌고, 팀원들의 로컬 히스토리와 충돌이 생깁니다. force push로 덮어쓰면 팀원의 커밋이 날아갈 수 있어요.

## 실무 패턴

```
개인 feature 브랜치 개발 중 → rebase main (로컬, push 전)
PR 올리기 전 커밋 정리 → interactive rebase
main에 병합 시 → squash and merge (GitHub) 또는 merge commit
```

squash and merge는 feature의 모든 커밋을 하나로 묶어서 main에 올립니다. main 히스토리는 깔끔하고, feature 작업 내역은 PR에서 확인 가능. 이게 대부분의 팀에서 권장하는 방식입니다.

## force push가 필요한 경우

interactive rebase 또는 amend 후에는 force push가 필요합니다. 개인 브랜치에서만, 절대 공유 브랜치에는 쓰지 마세요.

```bash
# 개인 feature 브랜치에서만 (안전한 버전)
git push --force-with-lease origin feature/my-work
```

`--force-with-lease`는 내가 인지하지 못한 원격 변경이 있으면 push를 중단합니다. `--force`보다 항상 이 옵션을 씁니다.