问题描述

我们在主干dev和branch1分支上进行并行开发。当要把branch1功能的代码合并到dev上时,发现dev上开发的部分功能代码找不到了。

那么,是在branch1上,作了删除提交导致的吗?然而,查提交日志,并没有发现删代码的提交记录。

难道一个分支有一个功能,另一个分支没这个功能,git合并时就有可能把这块功能代码丢掉?跟功能添加时间顺序有关系?

为了解决这个问题和相关的疑问,我们需要先了解下git合并的过程。

git-merge过程

稍微了解点git基础的应该都知道,合并是用的git merge命令。它只有两种,一种是快速合并(fast-forward),还有一种是三方合并(thirdparty merge)。

img

如上图所示,当两个分支有直系关系时,使用快速合并,git不产生新的commit结点,只是把head进行更新,如dev指向C4

三方合并稍显复杂点,它会产生一个新的commit结点,并把head指向它。它会先去找这两个要合并分支的最近公有结点,如图中,C3C5的最近公有父结点为C1。然后,git对 C1C3C5三个结点进行三方合并产生新结点C6。这里的三方合并,具体来说,就是把 C5相较于C1的 diff差异应用到 C3上,最后产生C6 这个commit结点。

现在回答上面的疑问,三方合并其实只看三个点的内容,和中间结点无任何关系,更别提跟时间有关系了。在一个分支上删除代码,如果合并时没有冲突的话,合并后是会直接删除的。

所以,我们找到了问题的初步方向了。dev上的代码合并后没了,一定是branch1分支有问题!!!

注:知道了git-merge的流程后,我们还可以知道,只要我们把这次合并代码丢失问题解决了,后续从branch1分支拉出去的分支代码再合并到dev时,都不用再解决这个代码丢失问题了。因为,合并后的提交结点和branch1分支拉出去分支的后续提交结点的父结点,已经变成branch1的当前结点了。如,C6的后续提交和C5的后续提交结点,公有结点都变成C5了。

问题起因及检测

为了描述问题方便,我把场景简化,搞了个demo,大家可以去下面地址clone:

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

提交记录用sourcetree看,是这样的(你可能已经发现问题了):

img

dev合并branch1时,dev上,dev func 1部分的提交丢失。

首先,让我们找最近公共结点吧。如果两个分支并行太久的话,可能不好直接找出来。我们可以使用git merge-base:

# git merge-base 98d19a4 0acedcb
9447776f5ee8c53536c947a1e13bfdead13f002b 

我们发现最近的公共结点是9447776。然而,这个公共结点,并不是我们设想的。我们设想的最近公共结点应该是两个分支刚开始并行的那个结点(如图中c3275e2)。进一步发现,9447776的下一个结点有个Merge,而且是把dev合并到branch1!!!

这就是问题的根源了,dev主干开发的一般是下个版本的功能,一般是把分支的代码合到主干上,把主干的代码逆向合并到分支上肯定是有问题的!!!

回到开头的问题,我们看Merge结点变更记录,并没有发现有删除代码的地方啊?原因是,你看到的合并结点的修改记录,是针对一边的。回到介绍三方合并的那个图,把branch1合并到dev产生结点C6,那么C6的提交记录中显示的修改,是C6针对C3结点的。在我们的示例中,合并结点74a8d10的提交变更,显示的是74a8d10对branch1中c26c5e3的变更,而branch1中本来就没有dev中的代码,所以合并后变更根本不会显示删除。

如果,你去比较合并结点和另一边的变更,你就可以发现问题:

# 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");
 }

你可以明显看到,在合并时,把dev中的dev_func_1函数删除掉了。

总结问题的原因是,在正式合并前,进行了逆向的合并,并在合并中悄悄把主干代码删除掉了。一般如果查看提交记录中,没有看到删除记录,那么很有可能是之前的Merge中把代码删除了。可以使用 merge-basegit diff 工具来进行定位,也可以用来检测是否有问题。

注:很多人可能认为只要管好自己的分支就行了,然后把别的分支合过来,并在合并时或合并后随意删除另一分支的代码。这样当以后再和该分支合并时,就会有问题。好的做法,应该是只把另一个分支上你需要的提交用cherry-pick移过来,而不是直接合并别人的分支,再删除你不需要的代码。如,只把dev上的fec5b84优化cherry-pick复制到branch1上即可。

解决思路

既然我们发现了问题的原因,并知道怎么去规避、检测。那么,如果已经发生了问题,怎么去解决呢?这个可能是大家更关心的。

其实我们最终的目标是,把branch1和dev进行合并,产生一个合并节点,并且这个合并结点的代码是正确的。

注:有些人可能不太明白为什么一定要产生一个git合并记录节点。通过各种手段,只要保证dev上代码正确不就行了?结论是不行,因为如果没有git合并记录的话,从branch1拉出来的所有分支再想合并到dev时,还是要解决下这个代码丢失的问题(没想明白,可以再看下前面git-merge过程部分),而且如果把branch1分支悬着不合并,也影响分支查看。

确保合并后代码正确

奔着这个目标,我们首先来确保代码的正确。

1. dev重置到合并前

既然最后合并branch1到dev会导致dev丢代码,我们首先把dev重置到合并前。

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

img

2. 创建tmp分支,绕过错误的合并74a8d10

我们知道branch1是有问题的,因为进行了合并dev的操作。所以,基于branch1创建一个临时分支tmp。

# git checkout branch1
# git checkout -b tmp

img

把tmp的提交记录重塑,使tmp分支回到branch1上的,合并dev到branch1那个错误的合并之前的结点,示例中 74a8d10之前的那个c26c5e3结点,并提交一个新记录,这样tmp内容与branch1一样,而完全跟那个74a8d10结点没关系了。

# git checkout tmp
# git reset c26c5e3
# git add .
# git commit -m "内容与branch1一致"

img

注:reset和reset –hard的区别,可以参考文末资料1。

3. 合并tmp到dev

# git checkout dev
# git merge tmp

这里dev和tmp合并时,它们的最近公共结点就不是之前错误的9447776了,而是我们设想的、dev和branch1最初分开的,c3275e2结点。

解决冲突,并add进暂存区后,我们代码就是正确的了(先不急着提交)。

img

产生合并commit对象

上面代码正确了,如果我们直接commit的话,这个合并结点,就变成dev和tmp的合并了,而我们要的是dev和branch1的合并。所以,我们要产生一个dev和branch1合并的结点,并且内容是当前dev和tmp合并后的代码。显然,git merge不能满足我们的需求,我们需要更底层的git命令,就是git merge过程中,调用的底层命令。

需要按序要用到 write-tree -> commit-tree -> update-ref,这三条底层命令。这部分命令,可以查看参考资料2。

1. write-tree产生tree对象

# git add .
# git write-tree
853c36012082314f9463f3819d0a24da49dc5bb1

我们产生了SHA-1值为 853c360的tree对象。

2. commit-tree产生commit对象

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

我们把tree对象 853c360进行了提交,并设置它的两个父结点为dev和branch1,产生了commit对象675baf3。我们可以看下这个结点的情况:

# 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指向这个新的commit对象, 675baf3

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

最终合并结果如下:

img

可以验证,branch1合并到dev了,而且内容是正确的(即不会少dev fun 1部分的代码)。

这个解决问题的示例代码,也上传到coding了,两份示例代码,之前的结点都是一致的。

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

注:知道了git merge这些底层命令,你可以更加灵活地解决git问题,你可以结点随意合并,head随便指,是不是很开心,哈哈。

更粗暴的方法

如果你觉得底层命令不好理解。你可以:

  • 先整个目录拷备下工程(包含.git目录),比如拷贝到bak目录
  • 在工程中直接合并branch1到dev上,不解决冲突,不提交
  • 在bak目录,按照上面确保代码正确的方法,在bak目录合并出正确的代码。
  • 把bak目录中,除了.git目录外的东东,全部拷贝覆盖到原来工程目录中
  • 在原来工程目录中,提交

这样比较好理解,缺点是工程如果大的话,拷来拷去花费时间比较长,而且不够优雅。

其他解决思路

上面描述的思路,我认为是最行之有效的。也试了其他思路,比如:

  • 查看git merge的参数,发现并没有可以自由设置base节点的方法,只有设置发现base节点的策略,而且这些策略发现的base节点都是那个错误的合并。
  • undo merge。参考资料3。然而,感觉revert merge的能力有限,加-m1参数、和-m2参数,均无法满足要求。
  • rebase branch1。错误发生在branch1,那么重建branch1呢?把所有branch1上合并后的提交都重新提交呢?结果发现branch1上有太多合并冲突,rebase时,要把这个合并的冲突重新解决,很麻烦。

这些思路,大家也可以继续研究下,感觉不能解决问题,也可能是我了解得有问题。当然,你有其他思路,也希望你交流下。

迷思

本文中,是因为错误地把dev合并到branch1上,导致了后面合并的问题。但是,我们真实遇到的场景,虽然看起来是一样的,也可以用文中的方法解决,但是也有细微不同,而且不知道如何出现这个问题。

真实的场景下,也会出现一个dev合并到branch1的Merge提交,但是显示的信息是 “Revert xxx”,据提交人员讲,这个确实是做的Revert操作,不知如何变成Merge结点了。用的sourcetree,提交人员也没法说清怎么必现这个问题。

如果,你知道怎么操作能出现这个问题,希望你告诉我。。。

总结

文中描述了一种可能导致git合并代码丢失的错误操作,并讲解了如何规避、检测、解决这种错误。并粗略介绍了,git merge流程,git merge底层过程。

说简单点,问题是因为悄悄在合并中把代码删除了。解决思路是,悄悄在后面的合并中把代码加回来。

参考

1. git-recipes

2. Git 内部原理-commit对象

3. Reverting a Merge