問(wèn)題描述

我們?cè)谥鞲蒬ev和branch1分支上進(jìn)行并行開(kāi)發(fā)碧浊。當(dāng)要把branch1功能的代碼合并到dev上時(shí)，發(fā)現(xiàn)dev上開(kāi)發(fā)的部分功能代碼找不到了瘟仿。

那么箱锐，是在branch1上，作了刪除提交導(dǎo)致的嗎劳较？然而驹止，查提交日志，并沒(méi)有發(fā)現(xiàn)刪代碼的提交記錄观蜗。

難道一個(gè)分支有一個(gè)功能臊恋，另一個(gè)分支沒(méi)這個(gè)功能，git合并時(shí)就有可能把這塊功能代碼丟掉墓捻？跟功能添加時(shí)間順序有關(guān)系抖仅？

為了解決這個(gè)問(wèn)題和相關(guān)的疑問(wèn)，我們需要先了解下git合并的過(guò)程砖第。

git-merge過(guò)程

稍微了解點(diǎn)git基礎(chǔ)的應(yīng)該都知道撤卢，合并是用的git merge命令。它只有兩種梧兼，一種是快速合并(fast-forward)凸丸，還有一種是三方合并(thirdparty merge)。

如上圖所示袱院，當(dāng)兩個(gè)分支有直系關(guān)系時(shí)，使用快速合并瞭稼，git不產(chǎn)生新的commit結(jié)點(diǎn)忽洛，只是把head進(jìn)行更新，如dev指向C4环肘。

三方合并稍顯復(fù)雜點(diǎn)欲虚，它會(huì)產(chǎn)生一個(gè)新的commit結(jié)點(diǎn)，并把head指向它悔雹。它會(huì)先去找這兩個(gè)要合并分支的最近公有結(jié)點(diǎn)复哆，如圖中，C3 和 C5的最近公有父結(jié)點(diǎn)為C1腌零。然后梯找，git對(duì) C1、C3和C5三個(gè)結(jié)點(diǎn)進(jìn)行三方合并產(chǎn)生新結(jié)點(diǎn)C6益涧。這里的三方合并锈锤，具體來(lái)說(shuō)，就是把 C5相較于C1的 diff差異應(yīng)用到 C3上，最后產(chǎn)生C6 這個(gè)commit結(jié)點(diǎn)久免。

現(xiàn)在回答上面的疑問(wèn)浅辙，三方合并其實(shí)只看三個(gè)點(diǎn)的內(nèi)容，和中間結(jié)點(diǎn)無(wú)任何關(guān)系阎姥，更別提跟時(shí)間有關(guān)系了记舆。在一個(gè)分支上刪除代碼，如果合并時(shí)沒(méi)有沖突的話呼巴，合并后是會(huì)直接刪除的泽腮。

所以，我們找到了問(wèn)題的初步方向了伊磺。dev上的代碼合并后沒(méi)了盛正，一定是branch1分支有問(wèn)題！Ｐ悸瘛豪筝！

注：知道了git-merge的流程后缴挖，我們還可以知道骄噪，只要我們把這次合并代碼丟失問(wèn)題解決了走贪，后續(xù)從branch1分支拉出去的分支代碼再合并到dev時(shí)蓄拣，都不用再解決這個(gè)代碼丟失問(wèn)題了者祖。因?yàn)檎希喜⒑蟮奶峤唤Y(jié)點(diǎn)和branch1分支拉出去分支的后續(xù)提交結(jié)點(diǎn)的父結(jié)點(diǎn)村象，已經(jīng)變成branch1的當(dāng)前結(jié)點(diǎn)了温艇。如逻恐，C6的后續(xù)提交和C5的后續(xù)提交結(jié)點(diǎn)像吻，公有結(jié)點(diǎn)都變成C5了。

問(wèn)題起因及檢測(cè)

為了描述問(wèn)題方便复隆，我把場(chǎng)景簡(jiǎn)化拨匆，搞了個(gè)demo，大家可以去下面地址clone：

# git clone https://git.coding.net/myswift/git-merge.git

提交記錄用sourcetree看挽拂，是這樣的（你可能已經(jīng)發(fā)現(xiàn)問(wèn)題了）：

dev合并branch1時(shí)惭每，dev上，dev func 1部分的提交丟失亏栈。

首先台腥，讓我們找最近公共結(jié)點(diǎn)吧。如果兩個(gè)分支并行太久的話绒北，可能不好直接找出來(lái)黎侈。我們可以使用git merge-base:

# git merge-base 98d19a4 0acedcb
9447776f5ee8c53536c947a1e13bfdead13f002b 

我們發(fā)現(xiàn)最近的公共結(jié)點(diǎn)是9447776。然而闷游，這個(gè)公共結(jié)點(diǎn)蜓竹，并不是我們?cè)O(shè)想的箕母。我們?cè)O(shè)想的最近公共結(jié)點(diǎn)應(yīng)該是兩個(gè)分支剛開(kāi)始并行的那個(gè)結(jié)點(diǎn)（如圖中c3275e2)。進(jìn)一步發(fā)現(xiàn)俱济，9447776的下一個(gè)結(jié)點(diǎn)有個(gè)Merge嘶是，而且是把dev合并到branch1！Ｖ肼怠聂喇！

這就是問(wèn)題的根源了，dev主干開(kāi)發(fā)的一般是下個(gè)版本的功能蔚携，一般是把分支的代碼合到主干上希太，把主干的代碼逆向合并到分支上肯定是有問(wèn)題的！Ｔ脱选誊辉！

回到開(kāi)頭的問(wèn)題，我們看Merge結(jié)點(diǎn)變更記錄亡脑，并沒(méi)有發(fā)現(xiàn)有刪除代碼的地方岸槌巍？原因是霉咨，你看到的合并結(jié)點(diǎn)的修改記錄蛙紫，是針對(duì)一邊的⊥窘洌回到介紹三方合并的那個(gè)圖坑傅，把branch1合并到dev產(chǎn)生結(jié)點(diǎn)C6，那么C6的提交記錄中顯示的修改喷斋，是C6針對(duì)C3結(jié)點(diǎn)的唁毒。在我們的示例中，合并結(jié)點(diǎn)74a8d10的提交變更星爪，顯示的是74a8d10對(duì)branch1中c26c5e3的變更枉证，而branch1中本來(lái)就沒(méi)有dev中的代碼，所以合并后變更根本不會(huì)顯示刪除移必。

如果，你去比較合并結(jié)點(diǎn)和另一邊的變更毡鉴，你就可以發(fā)現(xiàn)問(wèn)題：

# git diff 9447776 74a8d10

diff --git a/test.c b/test.c
index 150de8d..d19a020 100644
--- a/test.c
+++ b/test.c
@@ -7,8 +7,8 @@ void base_func() {
        printf("this is a crash %d\n", *p);
 }

-void dev_func_1() {
-       printf("dev func 1\n");
+void branch_func_1(){
+       printf("branch func1\n");
 }

你可以明顯看到崔泵，在合并時(shí)，把dev中的dev_func_1函數(shù)刪除掉了猪瞬。

總結(jié)問(wèn)題的原因是憎瘸，在正式合并前，進(jìn)行了逆向的合并陈瘦，并在合并中悄悄把主干代碼刪除掉了幌甘。一般如果查看提交記錄中，沒(méi)有看到刪除記錄，那么很有可能是之前的Merge中把代碼刪除了锅风∷址蹋可以使用 merge-base和git diff 工具來(lái)進(jìn)行定位，也可以用來(lái)檢測(cè)是否有問(wèn)題皱埠。

注：很多人可能認(rèn)為只要管好自己的分支就行了肮帐，然后把別的分支合過(guò)來(lái)，并在合并時(shí)或合并后隨意刪除另一分支的代碼边器。這樣當(dāng)以后再和該分支合并時(shí)训枢，就會(huì)有問(wèn)題。好的做法忘巧，應(yīng)該是只把另一個(gè)分支上你需要的提交用cherry-pick移過(guò)來(lái)恒界，而不是直接合并別人的分支，再刪除你不需要的代碼砚嘴。如十酣，只把dev上的fec5b84優(yōu)化cherry-pick復(fù)制到branch1上即可。

解決思路

既然我們發(fā)現(xiàn)了問(wèn)題的原因枣宫，并知道怎么去規(guī)避婆誓、檢測(cè)。那么也颤，如果已經(jīng)發(fā)生了問(wèn)題洋幻，怎么去解決呢？這個(gè)可能是大家更關(guān)心的翅娶。

其實(shí)我們最終的目標(biāo)是文留，把branch1和dev進(jìn)行合并，產(chǎn)生一個(gè)合并節(jié)點(diǎn)竭沫，并且這個(gè)合并結(jié)點(diǎn)的代碼是正確的燥翅。

注：有些人可能不太明白為什么一定要產(chǎn)生一個(gè)git合并記錄節(jié)點(diǎn)。通過(guò)各種手段蜕提，只要保證dev上代碼正確不就行了森书？結(jié)論是不行，因?yàn)槿绻麤](méi)有g(shù)it合并記錄的話谎势，從branch1拉出來(lái)的所有分支再想合并到dev時(shí)凛膏，還是要解決下這個(gè)代碼丟失的問(wèn)題（沒(méi)想明白，可以再看下前面git-merge過(guò)程部分)脏榆，而且如果把branch1分支懸著不合并猖毫，也影響分支查看。

確保合并后代碼正確

奔著這個(gè)目標(biāo)须喂，我們首先來(lái)確保代碼的正確吁断。

1. dev重置到合并前

既然最后合并branch1到dev會(huì)導(dǎo)致dev丟代碼趁蕊，我們首先把dev重置到合并前。

# git checkout dev
# git reset --hard HEAD~1

2. 創(chuàng)建tmp分支仔役，繞過(guò)錯(cuò)誤的合并74a8d10

我們知道branch1是有問(wèn)題的掷伙，因?yàn)檫M(jìn)行了合并dev的操作。所以骂因，基于branch1創(chuàng)建一個(gè)臨時(shí)分支tmp炎咖。

# git checkout branch1
# git checkout -b tmp

把tmp的提交記錄重塑，使tmp分支回到branch1上的寒波，合并dev到branch1那個(gè)錯(cuò)誤的合并之前的結(jié)點(diǎn)乘盼，示例中 74a8d10之前的那個(gè)c26c5e3結(jié)點(diǎn)，并提交一個(gè)新記錄俄烁，這樣tmp內(nèi)容與branch1一樣绸栅，而完全跟那個(gè)74a8d10結(jié)點(diǎn)沒(méi)關(guān)系了。

# git checkout tmp
# git reset c26c5e3
# git add .
# git commit -m "內(nèi)容與branch1一致"

注：reset和reset --hard的區(qū)別页屠，可以參考文末資料1粹胯。

3. 合并tmp到dev

# git checkout dev
# git merge tmp

這里dev和tmp合并時(shí)，它們的最近公共結(jié)點(diǎn)就不是之前錯(cuò)誤的9447776了辰企，而是我們?cè)O(shè)想的风纠、dev和branch1最初分開(kāi)的，c3275e2結(jié)點(diǎn)牢贸。

解決沖突竹观，并add進(jìn)暫存區(qū)后，我們代碼就是正確的了（先不急著提交）潜索。

產(chǎn)生合并commit對(duì)象

上面代碼正確了臭增，如果我們直接commit的話，這個(gè)合并結(jié)點(diǎn)竹习，就變成dev和tmp的合并了誊抛，而我們要的是dev和branch1的合并。所以整陌，我們要產(chǎn)生一個(gè)dev和branch1合并的結(jié)點(diǎn)拗窃，并且內(nèi)容是當(dāng)前dev和tmp合并后的代碼。顯然泌辫，git merge不能滿足我們的需求随夸，我們需要更底層的git命令，就是git merge過(guò)程中甥郑，調(diào)用的底層命令。

需要按序要用到 write-tree -> commit-tree -> update-ref荤西，這三條底層命令澜搅。這部分命令伍俘，可以查看參考資料2。

1. write-tree產(chǎn)生tree對(duì)象

# git add .
# git write-tree
853c36012082314f9463f3819d0a24da49dc5bb1

我們產(chǎn)生了SHA-1值為 853c360的tree對(duì)象勉躺。

2. commit-tree產(chǎn)生commit對(duì)象

# git commit-tree 853c360 -p 98d19a4 -p 0acedcb -m "Merge branch 'branch1' into dev"
675baf3973508ee03306cc5a36fe489d694e107f

我們把tree對(duì)象 853c360進(jìn)行了提交癌瘾，并設(shè)置它的兩個(gè)父結(jié)點(diǎn)為dev和branch1，產(chǎn)生了commit對(duì)象675baf3饵溅。我們可以看下這個(gè)結(jié)點(diǎn)的情況：

# git cat-file 675baf3 -p

tree 853c36012082314f9463f3819d0a24da49dc5bb1
parent 98d19a4a5913f18a2c0e9821e114df9995b23d82
parent 0acedcb89e4d25a0256fcbe7fba0bbc13de9d92e
author Vincent <xxx> 1498497182 +0800
committer Vincent <xxx> 1498497182 +0800

Merge branch 'branch1' into dev

3. 更新head

使用如下命令妨退，更新dev指向這個(gè)新的commit對(duì)象, 675baf3：

# git update-ref refs/heads/dev 675baf3

最終合并結(jié)果如下：

可以驗(yàn)證，branch1合并到dev了蜕企，而且內(nèi)容是正確的（即不會(huì)少dev fun 1部分的代碼）咬荷。

這個(gè)解決問(wèn)題的示例代碼，也上傳到coding了轻掩，兩份示例代碼幸乒，之前的結(jié)點(diǎn)都是一致的。

# git clone https://git.coding.net/myswift/git-merge2.git

注：知道了git merge這些底層命令唇牧，你可以更加靈活地解決git問(wèn)題罕扎，你可以結(jié)點(diǎn)隨意合并，head隨便指丐重，是不是很開(kāi)心腔召，哈哈。

更粗暴的方法

如果你覺(jué)得底層命令不好理解扮惦。你可以：

• 先整個(gè)目錄拷備下工程（包含.git目錄)臀蛛，比如拷貝到bak目錄

• 在工程中直接合并branch1到dev上，不解決沖突径缅，不提交

• 在bak目錄掺栅，按照上面確保代碼正確的方法，在bak目錄合并出正確的代碼纳猪。

• 把bak目錄中氧卧，除了.git目錄外的東東，全部拷貝覆蓋到原來(lái)工程目錄中

• 在原來(lái)工程目錄中氏堤，提交

這樣比較好理解沙绝，缺點(diǎn)是工程如果大的話，拷來(lái)拷去花費(fèi)時(shí)間比較長(zhǎng)鼠锈，而且不夠優(yōu)雅闪檬。

其他解決思路

上面描述的思路，我認(rèn)為是最行之有效的购笆。也試了其他思路粗悯，比如：

• 查看git merge的參數(shù)，發(fā)現(xiàn)并沒(méi)有可以自由設(shè)置base節(jié)點(diǎn)的方法同欠，只有設(shè)置發(fā)現(xiàn)base節(jié)點(diǎn)的策略样傍，而且這些策略發(fā)現(xiàn)的base節(jié)點(diǎn)都是那個(gè)錯(cuò)誤的合并横缔。

• undo merge。參考資料3衫哥。然而茎刚，感覺(jué)revert merge的能力有限，加-m1參數(shù)撤逢、和-m2參數(shù)膛锭，均無(wú)法滿足要求。

• rebase branch1蚊荣。錯(cuò)誤發(fā)生在branch1初狰，那么重建branch1呢？把所有branch1上合并后的提交都重新提交呢妇押？結(jié)果發(fā)現(xiàn)branch1上有太多合并沖突跷究，rebase時(shí)，要把這個(gè)合并的沖突重新解決敲霍，很麻煩俊马。

這些思路，大家也可以繼續(xù)研究下肩杈，感覺(jué)不能解決問(wèn)題柴我，也可能是我了解得有問(wèn)題。當(dāng)然扩然，你有其他思路艘儒，也希望你交流下。

迷思

本文中夫偶，是因?yàn)殄e(cuò)誤地把dev合并到branch1上界睁，導(dǎo)致了后面合并的問(wèn)題。但是兵拢，我們真實(shí)遇到的場(chǎng)景翻斟，雖然看起來(lái)是一樣的，也可以用文中的方法解決说铃，但是也有細(xì)微不同访惜，而且不知道如何出現(xiàn)這個(gè)問(wèn)題。

真實(shí)的場(chǎng)景下腻扇，也會(huì)出現(xiàn)一個(gè)dev合并到branch1的Merge提交债热，但是顯示的信息是 "Revert xxx"，據(jù)提交人員講幼苛，這個(gè)確實(shí)是做的Revert操作窒篱，不知如何變成Merge結(jié)點(diǎn)了。用的sourcetree，提交人員也沒(méi)法說(shuō)清怎么必現(xiàn)這個(gè)問(wèn)題墙杯。

如果济锄，你知道怎么操作能出現(xiàn)這個(gè)問(wèn)題，希望你告訴我霍转。。一汽。

總結(jié)

文中描述了一種可能導(dǎo)致git合并代碼丟失的錯(cuò)誤操作避消，并講解了如何規(guī)避、檢測(cè)召夹、解決這種錯(cuò)誤岩喷。并粗略介紹了，git merge流程监憎，git merge底層過(guò)程纱意。

說(shuō)簡(jiǎn)單點(diǎn)，問(wèn)題是因?yàn)?code>悄悄在合并中把代碼刪除了鲸阔。解決思路是偷霉，悄悄在后面的合并中把代碼加回來(lái)。

參考

1. git-recipes

2. Git 內(nèi)部原理-commit對(duì)象

3. Reverting a Merge