使用git rebase去掉无谓的融合

git pull 預設的行為是將遠端的 repo. 與本地的 repo. 合併，這也是 DVCS 的初衷，將兩個 branch 合併。但是，很多時候會發生以下這種情形：

這是因為，我們團隊的開發模式是本地的 branch 和遠端的 branch 會同步地非常頻繁(通常就是同名稱的 branch，例如 master)，這兩個 branch 幾乎是完全同步。這時候就會發現這些 merge 動作其實沒有必要，會造成線圖無謂的複雜。這時候，會推薦使用以下這個指令：

 git pull --rebase 

加上 rebase 的意思是，會先 1.把本地 repo. 從上次 pull 之後的變更暫存起來 2. 回復到上次 pull 時的情況 3. 套用遠端的變更 4. 最後再套用剛暫存下來的本地變更。詳細說明可以參考 pull with rebase。

畫圖說明一下好了:

假設合併前是這樣：

      D---E master
     /
A---B---C---F origin/master

使用 merge 合併後：

      D--------E
     /          \
A---B---C---F----G   master, origin/master

如果是 rebase 的方式，就不會有 G 合併點：

A---B---C---F---D'---E'   master, origin/master

注意到，其中 D’, E’ 的 commit SHA 序號跟本來 D, E 是不同的，因為算是砍掉重新 commit 了。

你會問說，有 conflict 怎麼辦? rebase 跟 merge 類似，出現 conflict 一會暫停 rebase 動作，需要你手動修復後，然後才可以繼續動作。這也是 rebase 比 merge 複雜一點的地方：merge 如果發生 conflict，你只需要解決衝突一次，然後 commit 出去就完成了。而 rebase 的 conflict 可能會發生在上述步驟 4 的每一次重新套用上，所以可能需要解決衝突好幾次 (rebase 時所謂的解決衝突，其實是直接修改你之前的變更內容，所以上圖中變成 D’ 跟 E’ )。

所以到底何時該用 merge? 何時可以 rebase? 你可能心理也有答案了，如果你修改比較多，預期會有較多的 conflict，建議用 merge (不過，如果是多次大範圍的主題式修改，那是不是應該一開始就多開一個 branch 來做呢?)。如果修改範圍較小，不太預期有 conflict，則建議可以加上 rebase 參數。

如果想要把 rebase 當做 git pull 的預設值，可以在專案的 .git/config 加上

[branch "master"]
  remote = origin
  merge = refs/heads/master
  rebase = true

也可以直接加到 ~/.gitconfig 讓所有的 tracked branches 都自動套用這個設定：

[branch]
  autosetuprebase = always