git合并丢失代码问题分析与解决(错误操作导致)
问题描述
我们在主干dev和branch1分支上进行并行开发。当要把branch1功能的代码合并到dev上时,发现dev上开发的部分功能代码找不到了。
那么,是在branch1上,作了删除提交导致的吗?然而,查提交日志,并没有发现删代码的提交记录。
难道一个分支有一个功能,另一个分支没这个功能,git合并时就有可能把这块功能代码丢掉?跟功能添加时间顺序有关系?
为了解决这个问题和相关的疑问,我们需要先了解下git合并的过程。
git-merge过程
稍微了解点git基础的应该都知道,合并是用的git merge命令。它只有两种,一种是快速合并(fast-forward),还有一种是三方合并(thirdparty merge)。
如上图所示,当两个分支有直系关系时,使用快速合并,git不产生新的commit结点,只是把head进行更新,如dev指向C4
。
三方合并稍显复杂点,它会产生一个新的commit结点,并把head指向它。它会先去找这两个要合并分支的最近公有结点,如图中,C3
和 C5
的最近公有父结点为C1
。然后,git对 C1
、C3
和C5
三个结点进行三方合并产生新结点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看,是这样的(你可能已经发现问题了):
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-base
和git 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
2. 创建tmp分支,绕过错误的合并74a8d10
我们知道branch1是有问题的,因为进行了合并dev的操作。所以,基于branch1创建一个临时分支tmp。
# git checkout branch1
# git checkout -b tmp
把tmp的提交记录重塑,使tmp分支回到branch1上的,合并dev到branch1那个错误的合并之前的结点,示例中 74a8d10
之前的那个c26c5e3
结点,并提交一个新记录,这样tmp内容与branch1一样,而完全跟那个74a8d10
结点没关系了。
# git checkout tmp
# git reset c26c5e3
# git add .
# git commit -m "内容与branch1一致"
注:reset和reset –hard的区别,可以参考文末资料1。
3. 合并tmp到dev
# git checkout dev
# git merge tmp
这里dev和tmp合并时,它们的最近公共结点就不是之前错误的9447776
了,而是我们设想的、dev和branch1最初分开的,c3275e2
结点。
解决冲突,并add进暂存区后,我们代码就是正确的了(先不急着提交)。
产生合并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
最终合并结果如下:
可以验证,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底层过程。
说简单点,问题是因为悄悄
在合并中把代码删除了。解决思路是,悄悄
在后面的合并中把代码加回来。