消除 Git 同步產生的惱人 Merge branch Commit

若你的 Git 專案有多人同時開發同一分支，在將修改結果 Push 到版控伺服器 (Github/TFS) 時應常會遇到以下狀況：

詳細訊息如下：

Error: failed to push some refs to 'https://github.com/darkthread/StepperExample.git'
Error: hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

原因很簡單，就是在取回最新版到修改完 Push 這段期間，版控主機上的分支已被其他人更新過，此時必須先將最新版 Pull 回本機才能 Push。

在 Visual Studio 遇到這種情況，解法是先點 Incoming Commits / Pull 抓回最新版，再點 Outgoing Commits / Push 上傳，或是直接點 Sync 一次做完 Pull + Push：

但有件煩人的事，每次 Pull 會產生一個名為 Merge branch 'master' of ... 的 Commit，若一堆人改得如火如荼，版本歷程圖便會生出一堆分叉線：

這樣有兩個缺點，一是平白增加一堆意義不大的 Commit，版本線圖也因此變得雜亂；第二，同是 master 分支，取回最新版也會產生 Merge 行為有違一般人對 Merge 的傳統認知 - 「融入其他 Branch 的內容」，常會使新手困惑。

針對這些缺點，git 提供了 pull --rebase 模式，以 Rebase 取代 Merge。( 對 Rebase 不熟悉的同學可參考龍哥的文章 另一種合併方式（使用 rebase） )。在 Visual Studio 2017+ ，如果想改用 pull --rebase，可透過 GUI 指定「Rebase local branch when pulling」：

修改後，Visual Studio 在 Pull 時會改以 Rebase 方式融入更新，不再產生額外的 Merge Commit，結果清爽許多：

至於改用 pull --rebase 的缺點，是遇到修改衝突時 Merge 只需解決衝突一次即可；Rebase 因需重算每一個尚未送出的本機 Commit，如果累積了五個 Outgoing Commits，就得解決衝突五次。若累積 Commit 較多又存在大量衝突，使用 Merge 較省事，實務上可視狀況彈性決定該用何者。