Git合并时同一文件不同行修改却触发冲突的原因及解决方法

问题根因 #

Git做三路合并判断冲突时，不是仅对比两个待合并分支的最终内容是否修改了同一行，还需要依赖变更行的相邻上下文定位修改的位置：

• 三个分支的共同祖先是master-base，branch-base仅修改了第一行内容，branch-a修改了第二、第三行内容
• branch-a修改的第二、三行的上邻上下文是master-base里的第一行内容Hello，但branch-base里的第一行已经被改成了Hello, my first conflict.
• Git无法在branch-base的内容里匹配到branch-a修改内容对应的相邻上下文，无法确定branch-a的修改应该插入到哪个位置，因此触发冲突。你看到的冲突块中HEAD侧为空，就是因为Git定位不到对应匹配位置。

解决方案 #

1. 解决当前冲突 #

当前冲突的预期合并结果非常明确，直接按照业务需要调整内容即可。如果要同时保留两个分支的所有修改，修改后的文件内容为：

Hello, my first conflict.
Second line.
Third line.a. # changed this line 

修改完成后执行git add <对应文件名>，再执行git commit即可完成合并。

2. 避免同类问题的前置方案 #

• 合并分支前先把目标分支的最新提交合入到当前开发分支，提前在开发分支解决冲突，避免合入目标分支时出现异常
• 关联性强的相邻行修改尽量在同一个分支内完成，减少跨分支修改相邻上下行的场景
• 如果需要多人协作修改同一公共文件，可以给文件加明确的模块分割注释，提升Git上下文匹配的准确率

内容的提问来源于stack exchange，提问作者Marwa Farouk