關於 Git 可以參考我的 Git 版本控制 課程資料
可以進一步參考 Git rebase 和 merge 合併操作示範錄影
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