“合并前文件還在的，合并后就不見(jiàn)了”、“我遇到 Git 合并的 bug 了” 是兩句經(jīng)常聽(tīng)到的話，但真的是 Git 的 bug 么?或許只是你的預(yù)期不對(duì)。本文通過(guò)講解三向合并和 Git 的合并策略，step by step 介紹 Git 是怎么做一個(gè)合并的，讓大家對(duì) Git 的合并結(jié)果有一個(gè)準(zhǔn)確的預(yù)期，并且避免發(fā)生合并事故。

故事時(shí)間

在開(kāi)始正文之前，先來(lái)聽(tīng)一下這個(gè)故事。

如下圖，小明從節(jié)點(diǎn) A 拉了一條 dev 分支出來(lái)，在節(jié)點(diǎn) B 中新增了一個(gè)文件 http.js，并且合并到 master 分支，合并節(jié)點(diǎn)為 E。這個(gè)時(shí)候發(fā)現(xiàn)會(huì)引起線上 bug，趕緊撤回這個(gè)合并，新增一個(gè) revert 節(jié)點(diǎn) E'。過(guò)了幾天小明繼續(xù)在 dev 分支上面開(kāi)發(fā)新增了一個(gè)文件 main.js，并在這個(gè)文件中 import 了 http.js 里面的邏輯，在 dev 分支上面一切運(yùn)行正常。可當(dāng)他將此時(shí)的 dev 分支合并到 master 時(shí)候卻發(fā)現(xiàn)，http.js 文件不見(jiàn)了，導(dǎo)致 main.js 里面的邏輯運(yùn)行報(bào)錯(cuò)了。但這次合并并沒(méi)有任何沖突。他又得重新做了一下 revert，并且迷茫的懷疑是 Git 的 bug。

兩句經(jīng)常聽(tīng)到的話：

—— ”合并前文件還在的，合并后就不見(jiàn)了“

—— ”我遇到 Git 的 bug 了“

相信很多同學(xué)或多或少在不熟悉 Git 合并策略的時(shí)候都會(huì)發(fā)生過(guò)類似上面的事情，明明在合并前文件還在的，為什么合并后文件就不在了么?一度還懷疑是 Git 的 bug。這篇文章的目的就是想跟大家講清楚 Git 是怎么去合并分支的，以及一些底層的基礎(chǔ)概念，從而避免發(fā)生如故事中的問(wèn)題，并對(duì) Git 的合并結(jié)果有一個(gè)準(zhǔn)確的預(yù)期。

如何合并兩個(gè)文件

在看怎么合并兩個(gè)分支之前，我們先來(lái)看一下怎么合并兩個(gè)文件，因?yàn)閮蓚€(gè)文件的合并是兩個(gè)分支合并的基礎(chǔ)。

大家應(yīng)該都聽(tīng)說(shuō)過(guò)“三向合并”這個(gè)詞，不知道大家有沒(méi)有思考過(guò)為什么兩個(gè)文件的合并需要三向合并，只有二向是否可以自動(dòng)完成合并。如下圖

很明顯答案是不能，如上圖的例子，Git 沒(méi)法確定這一行代碼是我修改的，還是對(duì)方修改的，或者之前就沒(méi)有這行代碼，是我們倆同時(shí)新增的。此時(shí) Git 沒(méi)辦法幫我們做自動(dòng)合并。

所以我們需要三向合并，所謂三向合并，就是找到兩個(gè)文件的一個(gè)合并 base，如下圖，這樣子 Git 就可以很清楚的知道說(shuō)，對(duì)方修改了這一行代碼，而我們沒(méi)有修改，自動(dòng)幫我們合并這兩個(gè)文件為 Print("hello")。

接下來(lái)我們了解一下什么是沖突?沖突簡(jiǎn)單的來(lái)說(shuō)就是三向合并中的三方都互不相同，即參考合并 base，我們的分支和別人的分支都對(duì)同個(gè)地方做了修改。

Git 的合并策略

了解完怎么合并兩個(gè)文件之后，我們來(lái)看一個(gè)使用 git merge 來(lái)做分支合并。如上圖，將 master 分支合并到 feature 分支上，會(huì)新增一個(gè) commit 節(jié)點(diǎn)來(lái)記錄這次合并。

Git 會(huì)有很多合并策略，其中常見(jiàn)的是 Fast-forward、Recursive 、Ours、Theirs、Octopus。下面分別介紹不同合并策略的原理以及應(yīng)用場(chǎng)景。默認(rèn) Git 會(huì)幫你自動(dòng)挑選合適的合并策略，如果你需要強(qiáng)制指定，使用git merge -s <策略名字>

了解 Git 合并策略的原理可以讓你對(duì) Git 的合并結(jié)果有一個(gè)準(zhǔn)確的預(yù)期。

Fast-forward

Fast-forward 是最簡(jiǎn)單的一種合并策略，如上圖中將 some feature 分支合并進(jìn) master 分支，Git 只需要將 master 分支的指向移動(dòng)到最后一個(gè) commit 節(jié)點(diǎn)上

Fast-forward 是 Git 在合并兩個(gè)沒(méi)有分叉的分支時(shí)的默認(rèn)行為，如果不想要這種表現(xiàn)，想明確記錄下每次的合并，可以使用git merge --no-ff。

Recursive

Recursive 是 Git 分支合并策略中最重要也是最常用的策略，是 Git 在合并兩個(gè)有分叉的分支時(shí)的默認(rèn)行為。其算法可以簡(jiǎn)單描述為：遞歸尋找路徑最短的唯一共同祖先節(jié)點(diǎn)，然后以其為 base 節(jié)點(diǎn)進(jìn)行遞歸三向合并。說(shuō)起來(lái)有點(diǎn)繞，下面通過(guò)例子來(lái)解釋。

如下圖這種簡(jiǎn)單的情況，圓圈里面的英文字母為當(dāng)前 commit 的文件內(nèi)容，當(dāng)我們要合并中間兩個(gè)節(jié)點(diǎn)的時(shí)候，找到他們的共同祖先節(jié)點(diǎn)(左邊第一個(gè))，接著進(jìn)行三向合并得到結(jié)果為 B。(因?yàn)楹喜⒌?base 是“A”，下圖靠下的分支沒(méi)有修改內(nèi)容仍為“A”，下圖靠上的分支修改成了“B”，所以合并結(jié)果為“B”)。

但現(xiàn)實(shí)情況總是復(fù)雜得多，會(huì)出現(xiàn)歷史記錄鏈互相交叉等情況，如下圖：

當(dāng) Git 在尋找路徑最短的共同祖先節(jié)點(diǎn)的時(shí)候，可以找到兩個(gè)節(jié)點(diǎn)的，如果 Git 選用下圖這一個(gè)節(jié)點(diǎn)，那么 Git 將無(wú)法自動(dòng)的合并。因?yàn)楦鶕?jù)三向合并，這里是是有沖突的，需要手動(dòng)解決。(base 為“A“，合并的兩個(gè)分支內(nèi)容為”C“和”B“)

而如果 Git 選用的是下圖這個(gè)節(jié)點(diǎn)作為合并的 base 時(shí)，根據(jù)三向合并，Git 就可以直接自動(dòng)合并得出結(jié)果“C”。(base 為“B“，合并的兩個(gè)分支內(nèi)容為”C“和”B“)

作為人類，在這個(gè)例子里面我們很自然的就可以看出來(lái)合并的結(jié)果應(yīng)該是“C”(如下圖，節(jié)點(diǎn) 4、5 都已經(jīng)是“B”了，節(jié)點(diǎn) 6 修改成“C”，所以合并的預(yù)期為“C”)

那怎么保證 Git 能夠找到正確的合并 base 節(jié)點(diǎn)，盡可能的減少?zèng)_突呢?答案就是，Git 在尋找路徑最短的共同祖先節(jié)點(diǎn)時(shí)，如果滿足條件的祖先節(jié)點(diǎn)不唯一，那么 Git 會(huì)繼續(xù)遞歸往下尋找直至唯一。還是以剛剛這個(gè)例子圖解。

如下圖所示，我們想要合并節(jié)點(diǎn) 5 和節(jié)點(diǎn) 6，Git 找到路徑最短的祖先節(jié)點(diǎn) 2 和 3。

因?yàn)楣餐嫦裙?jié)點(diǎn)不唯一，所以 Git 遞歸以節(jié)點(diǎn) 2 和節(jié)點(diǎn) 3 為我們要合并的節(jié)點(diǎn)，尋找他們的路徑最短的共同祖先，找到唯一的節(jié)點(diǎn) 1。

接著 Git 以節(jié)點(diǎn) 1 為 base，對(duì)節(jié)點(diǎn) 2 和節(jié)點(diǎn) 3 做三向合并，得到一個(gè)臨時(shí)節(jié)點(diǎn)，根據(jù)三向合并的結(jié)果，這個(gè)節(jié)點(diǎn)的內(nèi)容為“B”。

再以這個(gè)臨時(shí)節(jié)點(diǎn)為 base，對(duì)節(jié)點(diǎn) 5 和節(jié)點(diǎn) 6 做三向合并，得到合并節(jié)點(diǎn) 7，根據(jù)三向合并的結(jié)果，節(jié)點(diǎn) 7 的內(nèi)容為“C”

至此 Git 完成遞歸合并，自動(dòng)合并節(jié)點(diǎn) 5 和節(jié)點(diǎn) 6，結(jié)果為“C”，沒(méi)有沖突。

[[328002]]

Recursive 策略已經(jīng)被大量的場(chǎng)景證明它是一個(gè)盡量減少?zèng)_突的合并策略，我們可以看到有趣的一點(diǎn)是，對(duì)于兩個(gè)合并分支的中間節(jié)點(diǎn)(如上圖節(jié)點(diǎn) 4，5)，只參與了 base 的計(jì)算，而最終真正被三向合并拿來(lái)做合并的節(jié)點(diǎn)，只包括末端以及 base 節(jié)點(diǎn)。

需要注意 Git 只是使用這些策略盡量的去幫你減少?zèng)_突，如果沖突不可避免，那 Git 就會(huì)提示沖突，需要手工解決。(也就是真正意義上的沖突)。

Ours & Theirs

Ours 和 Theirs 這兩種合并策略也是比較簡(jiǎn)單的，簡(jiǎn)單來(lái)說(shuō)就是保留雙方的歷史記錄，但完全忽略掉這一方的文件變更。如下圖在 master 分支里面執(zhí)行g(shù)it merge -s ours dev，會(huì)產(chǎn)生藍(lán)色的這一個(gè)合并節(jié)點(diǎn)，其內(nèi)容跟其上一個(gè)節(jié)點(diǎn)(master 分支方向上的)完全一樣，即 master 分支合并前后項(xiàng)目文件沒(méi)有任何變動(dòng)。

而如果使用 theirs 則完全相反，完全拋棄掉當(dāng)前分支的文件內(nèi)容，直接采用對(duì)方分支的文件內(nèi)容。

這兩種策略的一個(gè)使用場(chǎng)景是比如現(xiàn)在要實(shí)現(xiàn)同一功能，你同時(shí)嘗試了兩個(gè)方案，分別在分支是 dev1 和 dev2 上，最后經(jīng)過(guò)測(cè)試你選用了 dev2 這個(gè)方案。但你不想丟棄 dev1 的這樣一個(gè)嘗試，希望把它合入主干方便后期查看，這個(gè)時(shí)候你就可以在 dev2 分支中執(zhí)行g(shù)it merge -s ours dev1。

Octopus

這種合并策略比較神奇，一般來(lái)說(shuō)我們的合并節(jié)點(diǎn)都只有兩個(gè) parent(即合并兩條分支)，而這種合并策略可以做兩個(gè)以上分支的合并，這也是 git merge 兩個(gè)以上分支時(shí)的默認(rèn)行為。比如在 dev1 分支上執(zhí)行g(shù)it merge dev2 dev3。

他的一個(gè)使用場(chǎng)景是在測(cè)試環(huán)境或預(yù)發(fā)布環(huán)境，你需要將多個(gè)開(kāi)發(fā)分支修改的內(nèi)容合并在一起，如果不用這個(gè)策略，你每次只能合并一個(gè)分支，這樣就會(huì)導(dǎo)致大量的合并節(jié)點(diǎn)產(chǎn)生。而使用 Octopus 這種合并策略就可以用一個(gè)合并節(jié)點(diǎn)將他們?nèi)亢喜⑦M(jìn)來(lái)。

Git rebasegit

rebase 也是一種經(jīng)常被用來(lái)做合并的方法，其與 git merge 的最大區(qū)別是，他會(huì)更改變更歷史對(duì)應(yīng)的 commit 節(jié)點(diǎn)。

如下圖，當(dāng)在 feature 分支中執(zhí)行 rebase master 時(shí)，Git 會(huì)以 master 分支對(duì)應(yīng)的 commit 節(jié)點(diǎn)為起點(diǎn)，新增兩個(gè)全新的 commit 代替 feature 分支中的 commit 節(jié)點(diǎn)。其原因是新的 commit 指向的 parent 變了，所以對(duì)應(yīng)的 SHA1 值也會(huì)改變，所以沒(méi)辦法復(fù)用原 feature 分支中的 commit。(這句話的理解需要這篇文章的基礎(chǔ)知識(shí))

對(duì)于合并時(shí)候要使用 git merge 還是 git rebase 的爭(zhēng)論，我個(gè)人的看法是沒(méi)有銀彈，根據(jù)團(tuán)隊(duì)和項(xiàng)目習(xí)慣選擇就可以。git rebase 可以給我們帶來(lái)清晰的歷史記錄，git merge 可以保留真實(shí)的提交時(shí)間等信息，并且不容易出問(wèn)題，處理沖突也比較方便。唯一有一點(diǎn)需要注意的是，不要對(duì)已經(jīng)處于遠(yuǎn)端的多人共用分支做 rebase 操作。

我個(gè)人的一個(gè)習(xí)慣是：對(duì)于本地的分支或者確定只有一個(gè)人使用的遠(yuǎn)端分支用 rebase，其余情況用 merge。

rebase 還有一個(gè)非常好用的東西叫 interactive 模式，使用方法是git rebase -i。可以實(shí)現(xiàn)壓縮幾個(gè) commit，修改 commit 信息，拋棄某個(gè) commit 等功能。比如說(shuō)我要壓縮下圖 260a12a5、956e1d18，將他們與 9dae0027 合并為一個(gè) commit，我只需將 260a12a5、956e1d18 前面的 pick 改成“s”，然后保存就可以了。

限于篇幅，git rebase -i 還有很多實(shí)用的功能暫不展開(kāi)，感興趣的同學(xué)可以自己研究一下。

總結(jié)

現(xiàn)在我們?cè)賮?lái)看一下文章開(kāi)頭的例子，我們就可以理解為什么最后一次 merge 會(huì)導(dǎo)致 http.js 文件不見(jiàn)了。根據(jù) Git 的合并策略，在合并兩個(gè)有分叉的分支(上圖中的 D、E‘)時(shí)，Git 默認(rèn)會(huì)選擇 Recursive 策略。找到 D 和 E’的最短路徑共同祖先節(jié)點(diǎn) B，以 B 為 base，對(duì) D，E‘做三向合并。B 中有 http.js，D 中有 http.js 和 main.js，E’中什么都沒(méi)有。根據(jù)三向合并，B、D 中都有 http.js 且沒(méi)有變更，E‘刪除了 http.js，所以合并結(jié)果就是沒(méi)有 http.js，沒(méi)有沖突，所以 http.js 文件不見(jiàn)了。

這個(gè)例子理解原理之后解決方法有很多，這里簡(jiǎn)單帶過(guò)兩個(gè)方法：1. revert 節(jié)點(diǎn) E'之后，此時(shí)的 dev 分支要拋棄刪除掉，重新從 E'節(jié)點(diǎn)拉出分支繼續(xù)工作，而不是在原 dev 分支上繼續(xù)開(kāi)發(fā)節(jié)點(diǎn) D;2. 在節(jié)點(diǎn) D 合并回 E’節(jié)點(diǎn)時(shí)，先 revert 一下 E‘節(jié)點(diǎn)生成 E’‘(即 revert 的 revert)，再將節(jié)點(diǎn) D 合并進(jìn)來(lái)。

Git 有很多種分支合并策略，本文介紹了 Fast-forward、Recursive、Ours/Theirs、Octopus 合并策略以及三向合并。掌握這些合并策略以及他們的使用場(chǎng)景可以讓你避免發(fā)生一些合并問(wèn)題，并對(duì)合并結(jié)果有一個(gè)準(zhǔn)確的預(yù)期。