git merge和rebase的區別2：對遠端分支的影響

上一篇中已經說明了 merge 和 rebase 會如何改變 commit 鏈路的結構，但有一些場景依然很模糊。

好比：若是遠端分支有一些提交了，客戶端也有一些提交了，客戶端 fetch 到數據後，再 merge ，產生了新的 commit 節點，這也是咱們知道的，那麼客戶端將變更 push 到遠端，遠端的 commit 結構會變成什麼樣呢？

我作了實驗確認了一下，遠端的分支就出現了分叉，再合併的狀況。

我想，這是很是很差的。形成上述狀況，僅僅是由於兩個程序員都基於某個 commit 節點開發，儘管沒有衝突，也會造成這樣一個分叉的結構。

假如咱們一個小組有 10 個成員，那麼豈不是這個遠程 commit 結構處處都分叉，而後又合併回去，這樣看起來是不太友好的。

因而我又實驗了一下 rebase
git pull --rebase
或者
git fetch
git rebase

我在遠程分支上線 push 了兩次提交，而後另外一個本地分支，commit 兩次提交，後執行git pull --rebase
來看看命令行的輸出：

git pull --rebase
First, rewinding head to replay your work on top of it...
Applying: a5
Applying: a6

它apply了a5和a6（這兩個就是我最近兩次commit提交的備註）

再來看看commit的結構：

如上圖所示，就是一個線性的結構。

但它有一個小毛病，咱們就按着這個圖來講。假如 b6 的提交其實是比 a5 晚的，但它卻排在了 a5 前面。也就是 commit 節點的順序和時間順序是不一致的。

但至少這樣，遠端的 commit 歷史是線性的了。

至於選擇 merge 和 rebase 應該是和團隊實際狀況考慮並選擇。