Git merge vs rebase: 협업에서 헷갈리지 않는 기준

merge와 rebase는 둘 다 브랜치를 합치지만, 히스토리를 남기는 방식이 다릅니다. 이 차이를 모르면 협업에서 사고가 납니다.

merge: 합친 기록을 그대로 남긴다

두 브랜치를 합치며 머지 커밋을 새로 만듭니다. 분기와 병합의 실제 흐름이 그대로 보입니다.

* 머지 커밋
|| * feature 커밋2
| * feature 커밋1
* | main 커밋
|/

장점: 안전하고 실제 작업 흐름이 보존됨. 단점: 머지 커밋이 많아 히스토리가 복잡.

rebase: 히스토리를 한 줄로 정리한다

내 커밋들을 main의 최신 커밋 위로 옮겨 붙입니다. 분기 흔적 없이 직선 히스토리가 됩니다.

* feature 커밋2 (재배치됨)
* feature 커밋1 (재배치됨)
* main 커밋

장점: 깔끔한 일직선 히스토리. 단점: 커밋 해시가 새로 생김(기존 커밋을 다시 씀).

절대 원칙: 공유 브랜치에 rebase 금지

이미 원격에 푸시해 남들과 공유 중인 브랜치를 rebase하면, 히스토리가 갈라져 모두의 작업이 꼬입니다. rebase는 아직 나만 가진 로컬 브랜치에서만 쓰세요.

상황	추천
내 기능 브랜치를 main 최신으로 업데이트	rebase(로컬)
기능 완료 후 main에 통합	merge(--no-ff)
이미 공유된 브랜치	rebase 금지, merge

실무 워크플로 예시

# 작업 중 main 변경을 내 브랜치에 반영(로컬에서만)
git fetch origin
git rebase origin/main

# 충돌 해결 후
git rebase --continue

# 완료된 기능을 main에 통합(PR 머지)
git merge --no-ff feature

마무리 체크리스트

• merge = 흐름 보존, rebase = 깔끔한 직선
• rebase는 로컬 전용, 공유 브랜치엔 금지
• 충돌은 단계마다 해결 후 --continue
• 팀 규칙(머지 커밋 허용 여부)을 먼저 합의

"공유 브랜치엔 rebase 안 한다" 한 줄만 지켜도 Git 사고의 대부분을 피합니다.