Git Merge异常行为咨询：为何自动覆盖未触发冲突？

问题场景 #

本地Git仓库提交结构如下：

O-A-B
  \
   C

• B 位于 master 分支
• B 和 C 均基于共同祖先 A 做了内容修改
• 期望合并 C 到 B 后生成新提交 D，保留两者的修改，最终结构：

O-A-B-D
  \  /
   C

具体示例 #

• 提交A的文件内容：

  foo = true
  bar =  1
  

• 提交B的文件内容：

  foo = false
  bar = 1
  

• 提交C的文件内容：

  foo=true
  bar = 2
  

• 预期提交D的内容：

  foo=false
  bar = 2
  

执行操作：检出B并执行合并C的命令，预期Git会检测到文件差异触发冲突，需要手动编辑后提交，但实际Git直接用C的内容覆盖了B，自动完成合并，D完全等同于C。已撤销该合并，改用git difftool手动合并，需明确原因。

原因分析 #

Git的合并基于三方合并逻辑：以共同祖先A为基准，分别对比B相对于A的修改、C相对于A的修改，再尝试将这两组修改合并到A的版本上。是否触发冲突，取决于Git对两组修改的判断：

1. 修改区域的识别逻辑 #

在你的示例中：

• B 相对于 A 的修改：
  • foo 行：将值从 true 改为 false，格式未变
  • bar 行：去掉等号后的多余空格，值保持为 1
• C 相对于 A 的修改：
  • foo 行：去掉等号两边的空格，值保持为 true
  • bar 行：将值从 1 改为 2，格式未变

Git的diff算法可能将foo行的两组修改识别为同一行的不同变更，但由于这两个变更没有直接的内容冲突（一个改值、一个改格式），理论上应能自动合并为foo=false（结合值的修改和格式的修改）。但你遇到C直接覆盖B的情况，大概率是以下配置或算法判断问题：

2. 关键配置或策略影响 #

• 空格处理配置：如果你的Git配置了core.whitespace忽略空格差异，或者merge.renormalize=true，可能导致Git在对比时忽略B对bar行的空格修改，同时将foo行的格式修改和值修改判定为“可兼容”，进而选择C的版本作为合并结果。
• 合并策略的默认行为：Git默认使用recursive合并策略，当遇到同一行的两组修改无法自动合并时，部分场景下会默认选择待合并分支（即C所在分支）的版本，而非触发冲突。这种情况常见于两组修改都属于整行替换，且Git无法判定优先级时。
• 行结束符差异：如果B和C的文件行结束符不同（比如一个是LF、一个是CRLF），Git在diff时可能无法正确识别B的修改，进而认为B相对于A没有变更，直接应用C的修改。

3. 验证方式 #

可以通过以下命令查看三方合并的差异细节，确认Git的判断逻辑：

git diff --no-index --merge A B C

该命令会模拟三方合并的对比过程，展示Git如何识别两组修改的冲突情况。

内容的提问来源于stack exchange，提问作者bob.sacamento