git conflict冲突

总结一下在工作中遇到的冲突及避免的办法，

一、修改同一处代码引起的冲突

git主要有master，release，dev，feature等分支，
以dev/feature分支为例，主要用于开发测试主分支。

 

demo在feature合并dev分支的时候会出现的冲突。

dev环境的版本

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.ArrayList;
import java.util.List;

 

feature_A的版本

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.List;

feature_B的版本

import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.List;

下面展示是如何造成冲突的：

这个时候feature_B 加了2个import
feature_B的版本变为：

import java.text.SimpleDateFormat;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.ArrayList;
import java.util.List;

显然这个时候和staging的版本造成冲突：

import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.ArrayList;
import java.util.List;

git合并的时候会进行three-way merge，
这个时候有歧义性：
1、第一种合并方案
认为你的版本删除了feature_A的

import java.util.Date;

又增加了两行

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

最终结果为：

import java.text.SimpleDateFormat;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.ArrayList;
import java.util.List;

2、第二种合并方案，
即不删除feature_A的

import java.util.Date;

最终合并方案为：

import java.text.SimpleDateFormat;
import java.util.Date;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.ArrayList;
import java.util.List;

避免这种情况的最好方法是import总是放在自己的代码中间，import不要交错放。禁止使用代码格式化工具，尽量手动格式化。

二、改动他人代码引起冲突：

另外一种冲突的原因是因为改动了他人的代码，这个是很危险的，非常容易引起冲突和bug。

三、文件引起的冲突

因为共同创建了一个同名文件，对方删除了我们正在使用的文件。也会引起冲突，叫做树冲突。

比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。

如果最终确定用b.c，那么解决办法如下：
git rm a.c
git rm origin-name.c
git add b.c
git commit

 

 

例子：引发此问题描述和背景

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

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

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

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

git-merge过程

git合并是用的git merge命令。它只有两种，一种是快速合并(fast-forward)，还有一种是三方合并(thirdparty merge)。

快速合并(fast-forward)：当两个分支有直系关系时，使用快速合并，git不产生新的commit结点，只是把head进行更新。

三方合并(thirdparty merge)：三方合并稍显复杂点，它会产生一个新的commit结点，并把head指向它。它会先去找这两个要合并分支的最近公有结点，git对 C1、C3和C5三个结点进行三方合并产生新结点。这里的三方合并，具体来说，就是把后新节点相较于之前共有节点的 diff差异应用，最后产生新commit结点。

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

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

问题起因及检测

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

 

解决思路

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

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

 

确保合并后代码正确

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一致"

3. 合并tmp到dev

# git checkout dev
# git merge tmp

这里dev和tmp合并时是我们设想的dev和branch1最初分开的结点。

解决冲突，并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

更粗暴的方法

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

• 先整个目录拷备下工程（包含.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底层过程。

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