在使用 Git 進行版本控制時，我們經常會遇到要把branch合併的時候。通常我們比較容易看到大家選擇使用 merge ，但其實如果我們可以搭配使用 rebase ，可以讓整棵tree不至於產生太多合併點，讓commit的歷程更整潔。今天我們就一起來聊聊，什麼樣的情況裡面選擇 rebase 可能會比 merge 更好吧！

合併操作的比較

假設我們的現在的情況是這樣：

如果我們選擇使用 merge 來合併 main 和 develop ，合併後的結果會是這樣：

在這個合併中，Git 會新增一個節點 E，來代表 main 和 develop 在這裡合併了。雖然這樣看起來很完整的保留了歷程，可是我們在這裡其實只有累積了4個版本，但現在看起來卻有5個點。而那個多出來的點，就是那個只是因為merge才自動產生的節點 E。

這樣反覆操作、合併很多次之後，看起來就會變得很亂，維護起來也會變得麻煩。

這時候如果我們改成使用 rebase，合併後的結果就會看起來簡潔許多：

在這裡，我把 D 重寫為 D' ，是因為經過rebase之後，它的 commit SHA 就會和原本不一樣了，我們可以把它想成是因為 rebase 實際上是重新commit了一次。這樣子做完的結果看起來更線性，就像所有變更都沿著一條直線進行，沒有多餘的分叉，而且一看就能知道最新的版本是D'，而不會像前面誤認成是節點 E了。

那什麼時候應該使用 merge？

不過雖然 rebase 有很多優點，但不表示我們就應該要捨棄 merge 而不用它。因為其實在很多情況下，保留合併歷史還是有它的價值在，比如說：

• 多人協作的場景：當多個開發者同時在不同的branch上進行開發時，使用 merge 可以保留每個人的工作歷史，並顯示出每個branch是怎麼合併到一起的，這對於到時候要計算工作產出與權責歸屬就是很重要的依據。
• 已經push到遠端的branch：如果你的branch已經push出去到遠端了，就不建議再使用 rebase，因為這樣會動到其他人都已經看到的修改歷程，可能反而影響到其他開發者的工作。

小結

rebase 和 merge 其實各有好處。如果是在個人、本地端的開發環境下，可以考慮多使用 rebase 來維持整條線的乾淨。但如果在一些需要保留完整歷程的情況下 (比如多人協作、開源等複雜的環境)，貿然使用 rebase 來整理反而可能產生不可逆的風險；如果不能確保這麼做絕對安全的話，使用 merge 來做還是會比較保險。