Rebase vs merge: 모양과 의도
둘 다 한 branch 의 작업을 다른 branch 로 통합. 차이는 history 에 무슨 짓을 하느냐. Merge 는 두 parent 가진 새 commit 으로 두 history 를 Y-junction 에서 합침 — 두 line 다 graph 에 visible. Rebase 는 source branch commit 을 target tip 위에 새 commit 으로 replay — 결과는 merge commit 없는 단일 선형 chain. 같은 content, 아주 다른 모양.
실용적 결정 트리. Merge 써 — 발산이 의미 있을 때: 장기 release branch 통합, 기능 완성을 작업 단위로 표시, compliance 용 '어디서 왔는지' audit trail 보존. Rebase 써 — 발산이 우연일 때: 짧은 feature branch — 그 commit 들은 main 에 'merge of main into feature/x' 같은 noise 추가. 매일 ship 하는 대부분 제품 팀엔 feature branch 에 rebase 가 승 — main 이 tangle 이 아니라 기능들의 단일 시퀀스로 읽혀.
팀 정책 형태: 셋 중 하나 선택. (a) 선형 history — 모든 PR 이 main 에 rebase + fast-forward merge, main 은 한 chain. (b) 항상 merge — 모든 PR 이 fast-forward 가능해도 merge commit 생성 (--no-ff), main 에 visible feature 단위. (c) Merge 시 squash — 모든 PR commit 이 main 에 1 commit 으로 collapse, 내부 구조 무관. 각자 내적으로 일관됨. 섞는 게 진짜 문제.
실전 명령 둘. git rebase main 을 feature branch 에서 = local commit 을 main 의 현재 tip 에 replay. Conflict 는 interactive mode 처럼 rebase 를 일시정지, 해결 후 git rebase --continue. git rebase --onto <new-base> <old-base> <branch> 는 branch 를 한 base 에서 다른 base 로 이동 — 처음에 잘못된 곳에서 분기했을 때 유용.