Git rebase 自身冲突原因分析与处理

Git rebase工作原理概述

在我们的项目中，假设当前的分支状态如下：

...--o--*--A--B          <-- master
         \
          C--D--...--Z   <-- feature

master当前指向commit B，在“*号”commit创建了分支feature，并进行了多次提交：C到Z。

当在分支feature上执行git rebase master后。git定位到*号这次提交。随后需要将Commit C至Z复制到master当前指向的头部。我们暂时用C’、D’代表复制到master头部的这些commit，随后提交的分支图如下：

                C'-D'-...-Z'   <-- feature
               /
...--o--*--A--B                <-- master
         \
          C--D--...--Z         [舍弃]

为了改变feature分支切出时的基准，由于feature和master涉及多次提交，因此经历下面的变换过程。

将C’改变其基准，需要分析*号到B和 *号到C之间的差异，尝试进行合并，而这次比较中可能存在冲突，因此产生第一次合并冲突。

                C'       <-- HEAD (rebase in progress)
               /
...--o--*--A--B          <-- master
         \
          C--D--...--Z   <-- feature

随后移动D，比较D与C’的差异。如果产生冲突则需要处理。后续处理时过程类似。即以一个最近公共祖先为比较基础，找出每个块的差异看是否有冲突。

当我们在feature分支上多次对同一个文件的同一段代码多次修改，并多次提交。最后rebase master时，会出现处理多次自身冲突的问题。最终多次解决，并使用git rebase --continue完成分支基准修改。

解决

可以多次重复进行冲突处理，直到解决。或者将多次自身产生冲突的commit进行合并为一次commit，随后再进行rebase。

总结

理解工具大致的工作原理，选择一种办法解决。

参考

[1]git rebase 冲突处理,https://stackoverflow.com/questions/42424432/git-rebase-how-to-deal-with-conflicts