rebase vs. merge

因為「換掉起點」不是只把 parent 欄位改個指向,而是要把你的改動重新套用到一份可能已經不一樣的程式碼上。衝突就出在「可能不一樣」這五個字。

回想上面第二步:rebase 把 D、E 抽成 patch,而 patch 記的不是「檔案最終長怎樣」,是「在某幾行附近,把這幾行換成那幾行」(還帶著上下幾行當定位用的 context)。第三步「在 C 之後重放」,實際做的是把 patch 貼到 C 的內容上:

patch D 想做的: 第 42 行  "你好"  →  "Hi"     （這是站在 B 寫的）
但 C 已經把  : 第 42 行  "你好"  →  "Hello"  （main 上也動了同一行）
                          ▲ 同一塊被兩邊各改成不一樣 → 撞上 → 衝突

所以衝突從來不是「換 parent」這個動作造成的,而是「你的改動」和「新 base 上的改動」碰到了同一段。把 patch 想成一塊磁磚:起點換掉等於把它重貼到新地基上——地基沒動到那一處,Git 默默貼好、毫無衝突;地基在同一處也被改過,就貼不平、停下來請你裁決,標記跟第 6 章一模一樣的 <<< === >>>。

順帶一提,這也解釋了一個常見的痛點——rebase 的衝突可能要解很多次:

兩者判定衝突的規則完全相同(同一塊 hunk 雙方都改,見第 6 章),差別只在 merge 一次結清、rebase 一顆一顆貼所以可能反覆遇到。還有個容易忽略的邊角:就算 C 沒改到你那幾行、卻改到了 patch 用來定位的上下文 context,也可能讓 patch「對不準」而衝突——這就是第 6 章「相鄰行保守判定」在 rebase 裡的版本。

-i 是 rebase 的「手動駕駛模式」。普通 git rebase main 把你的 commit 原封不動逐一重放到新 base;加上 -i,Git 會在重放前先打開一份「待辦清單」,讓你逐顆決定每個 commit 怎麼處理——改順序、合併、改訊息、丟掉都行。本質還是 7.1 那套(抽 patch → 重放 → 全新 SHA),所以一樣別對已推送的分支做(7.3)。

最常見的用途不是接到別條分支,而是整理自己最近幾顆 commit:

git rebase -i HEAD~4     # 整理最近 4 顆;清單順序是「舊在上、新在下」

下面這個模擬器就是一份 git rebase -i HEAD~4 的待辦清單。改每列左邊的動作、用 ▲▼ 調順序,再按套用 rebase,看 Git 會把歷史重建成什麼樣(預設已示範:兩個 typo 用 fixup 併掉):

幾個關鍵點:squash vs fixup 都合併,差別只在要不要留被併者的訊息;edit 能拆 commit(暫停後 git reset HEAD^ 退回改動,再分多次 commit);中途撞衝突照樣可能發生(原因見上一則問答),解完 git rebase --continue、想整個放棄用 git rebase --abort;真的整理壞了,git reflog 救得回(第 9 章)。

rebase 停下來的時候,Git 其實是在問你一個問題:「這一顆貼不上去,你要怎麼辦?」三個指令就是三種回答。分辨它們只要抓一個維度——你要丟掉的是「這一顆」,還是「整場 rebase」?

那 --skip 什麼時候才是正解?答案是:當這顆 patch 已經沒有意義的時候——它想做的改動,新 base 上早就有人做過了。這時貼上去等於什麼都沒改,留著只會多一顆空 commit。最常見的兩個場景:

• 你的 commit 被 cherry-pick 或 squash merge 進 main 了:內容已經在新 base 裡,再貼一次是重複。
• 你解衝突時,決定「整段都採用新 base 的版本」:等於這顆什麼都不改了。

這種情況 Git 通常會自己提示你,訊息長這樣:

$ git rebase --continue
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to skip this commit, use:

    git rebase --skip

看到 Git 主動說 now empty / 建議你 skip,那才是按 --skip 的時機。其他時候看到衝突就想 skip,幾乎都是誤按。

完全沒有違反,而且這正是 rebase 最常見、最安全的用法。很多人第一次碰 rebase 就是這個情境,又剛好讀到黃金法則,結果嚇得不敢按下去——這裡把界線畫清楚。

關鍵在於黃金法則管的是「被重寫的是哪幾顆 commit」,不是「你 rebase 到哪裡去」。git rebase origin/main 這行指令裡,origin/main 是新的 base(目的地),它一根寒毛都不會被動到;被抽成 patch、重建成新 SHA 的,是你自己那幾顆還沒推送的 commit。沒推送 → 沒人基於它們工作 → 重寫它們不會傷到任何人。

把兩個情境並排看,界線就很清楚了:

所以真正的判準只有一句:rebase 前先問「我要被重寫的那幾顆,推出去過嗎?」沒有 → 放心做;有 → 回頭看上面那串實務推論。

那為什麼這情境要用 --rebase 而不是預設的 git pull(= fetch + merge)?因為預設的 merge 會替你生一顆 Merge branch 'main' of github.com:… 的 merge commit——它不代表任何有意義的功能合入,純粹是「我 pull 的時候剛好落後了」的雜訊。每個人每天 pull 幾次,歷史就被這種菱形塞爆。--rebase 則是把你的 commit 挪到最新進度後面,歷史保持一條直線:

git pull --rebase                       # 這次 pull 用 rebase 追上
git config --global pull.rebase true    # 一勞永逸:以後 pull 預設都用 rebase
git config --global rebase.autoStash true   # 順手:工作區有未 commit 的改動也不用先手動 stash