Git在master无改动时合入dev为何触发非预期合并冲突

很多团队都会遇到这种“master从来没改过相关文件、却全是dev分支改动对应的合并冲突”的问题，本质上不是Git的合并逻辑出错，而是几个常见的操作偏差触发了合并引擎的误判：

• 分支提交历史错位，找不到正确的共同合并基线
  Git执行合并的核心前提，是找到两个分支从同一起点分叉出来的那个共同祖先提交，作为计算改动的基准。如果之前合入master的操作没有留下正式的合并关联——比如之前上线时用squash方式合入、手动把dev文件内容覆盖到master后单独提交、甚至因为误操作强制推送重写了master的提交历史——Git就会在找共同祖先的时候，定位到非常久远的、早于上次上线的老提交作为计算基线。
  这时候合并引擎会判断：master相对于这个老基线已经修改过一批文件内容，dev相对于同一个老基线也修改过同一批内容，哪怕master上的修改就是之前dev分支的内容，也会被判定为“两边同时修改了同一行”，触发全量冲突。
• 不可见的文件格式差异，最常见的是换行符不匹配
  如果团队没有统一配置Git的换行符自动转换规则，很容易出现dev分支上的文件换行符是CRLF（Windows环境默认），而master分支上存的是LF（Linux环境默认、CI部署环境常用）的情况。这类差异是肉眼不可见的，但Git逐行对比的时候，会把每一行因为结尾换行符不同的内容，都判定为两边都做了修改，最终所有dev上的改动都会被标记为冲突，而且打开冲突文件会发现，master侧的内容看起来和老版本完全一样，根本找不到实际的有效改动。
• 文件编码、文件权限差异触发的全文件匹配失败
  少数情况下，如果dev分支上的文件被本地编辑器自动转成了带BOM头的UTF-8编码，或者文件可执行权限被改动，也会导致Git逐行对比时出现全文件级别的差异，进而触发冲突。

这里需要明确一个核心工作机制：

Git的自动合并从来不是“将dev分支的所有改动直接覆盖到master分支”。它的工作流程是先锁定共同祖先基线，再分别计算master、dev两个分支相对于这个基线的改动范围，最后把两边的改动叠加到基线内容上。只要引擎检测到两个分支相对于基线，对同一行内容都做了修改，不管两边修改的结果是不是一致，都会直接标记为冲突，等待人工确认，绝对不会自动帮你选择保留某一侧的内容。

正常场景下，如果master从上次合并到现在没有任何改动，那master侧相对于共同基线的改动量就是0，合并引擎根本不会检测到两边同时修改同一行的情况，自然不会触发冲突。只要出现了这类异常冲突，本质上都是合并引擎找错了计算基线，或者被不可见的格式差异误导，误判了两边的改动范围。

遇到这类问题可以按顺序排查：

• 本地拉取最新的master和dev分支，执行git merge-base master dev，对照输出的commit哈希值，确认这个提交是不是上次上线合并完成、dev开始本次开发之前的正确基线，如果不是，就说明是历史操作导致的基线错位问题。
• 检查本地的Git换行符配置，执行git config --global core.autocrlf，统一团队的配置规则，避免自动转换换行符导致的全文件差异。
• 检查master分支的提交历史，确认所有合入的操作都是正式的merge提交，没有出现squash合并、手动覆盖提交、强制推送重写历史的操作，切断分支间的提交关联。

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