三路合并

和其他版本控制系統(tǒng)不同，Git 提供的合并沖突解決方案并不會(huì)聰明過(guò)頭，不會(huì)嘗試自動(dòng)將所有問(wèn)題都解決。Git 的設(shè)計(jì)哲學(xué)是智能判斷一個(gè)合并是否可以非常容易地自動(dòng)完成，如果自動(dòng)化方案不可行，就不要自作聰明地去嘗試解決它，最好讓用戶自己去解決合并沖突。

文件層面

通過(guò)比較共同的祖先（base）、當(dāng)前分支（ours），待合并分支（theirs），Git 采用三路合并算法生成合并結(jié)果。該算法至少在文件目錄層面非常簡(jiǎn)單。其規(guī)則如下：

祖先（base）HEAD（ours）分支（theirs）結(jié)果說(shuō)明

A	A	A	A
A	A	B	B	如果一方修改了某個(gè)文件，選擇修改版的文件
A	B	A	B	如果一方修改了某個(gè)文件，選擇修改版的文件
A	B	B	B	如果雙方擁有相同的變更，選擇修改過(guò)的版本
A	B	C	merge	如果一方包含與另一方不一樣的變更，那么在內(nèi)容層面存在合并沖突

內(nèi)容層面

如果是最后一行的情況，那么 Git 就會(huì)在內(nèi)容上嘗試合并。我們舉個(gè)例子，假設(shè)提交圖如下：

B-C-D master(*)\E-F dev

目前所在分支是 master，當(dāng)嘗試把 dev 合并入 master 分支時(shí)，base 是提交 B，ours 是提交 D，theirs 是提交 F.

B、D、F 三個(gè)提交都有 foo.c 這個(gè)文件，它們的內(nèi)容分別如下：

請(qǐng)問(wèn) Git 會(huì)怎么合并 ours 和 theirs 呢？

當(dāng)然需要參考他們的共同祖先 base, 下圖標(biāo)出了ours 和 theirs 分別與祖先不同的地方（用下劃線及藍(lán)色背景表示）。

祖先（base）HEAD（ours）分支（theirs）結(jié)果說(shuō)明

A	A	A	A
A	A	B	B	如果一方修改了某一行，那么這一行選擇修改版的
A	B	A	B	同上
A	B	B	B	如果某一行雙方擁有相同的變更，則選擇修改過(guò)的行
A	B	C	conflict	如果某一行雙方都修改了，且修改得不一樣，則報(bào)告沖突，需要用戶解決

根據(jù)上表的規(guī)則，合并過(guò)程類似這樣：

可以看到，第四行，雙方都修改了，且各自修改的內(nèi)容不一樣，所以 Git 不知道怎么解決，所以就把問(wèn)題拋給用戶了。

遞歸三路合并（Recursive three-way merge）

三路合并算法的基礎(chǔ)是找到被合并文件的共同祖先文件。在遇到十字交叉合并（criss-cross merge）時(shí)，不存在獨(dú)一無(wú)二的最小共同祖先。如下圖所示，merge D 和 F 時(shí)，發(fā)現(xiàn) C 和 E 都是它們的公共祖先，這可怎么辦，C 和 E 哪一個(gè)作為 Base 呢？

B--C--D master\ \/\ /\E--F dev

Git 的策略是：先合并 C 和 E 得到一個(gè)虛擬的公共祖先 G，把這個(gè) G 作為 Base. 那如果合并 C 和 E 的時(shí)候發(fā)現(xiàn)他們的公共祖先也不止一個(gè)怎么辦？所以就要遞歸進(jìn)行了。

如下圖：合并 M 和 N，發(fā)現(xiàn)他們的共同祖先有2個(gè)——L 和 K，于是合并 L 和 K，又發(fā)現(xiàn)他們的祖先不止一個(gè)——I 和 J，于是合并 I 和 J，就這樣遞歸下去。

B--C---D--I--L--M master\ \/ \/ \ /\ /\E---F--J--K--N dev

---

參考資料

【1】《Git 高手之路》，人民郵電出版社

【2】https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge

【3】http://blog.fedeoo.cn/2017/02/22/git-合并策略-之-recursive/

總結(jié)

以上是生活随笔為你收集整理的三路合并 —— Git 学习笔记 17的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。