Git合并master至dev时m1代码被m2无提示覆盖，咨询原因及复现失败问题

核心合并逻辑导致无提示覆盖 #

Git执行合并时采用三方合并机制，当你在dev分支合并master时，会以4月26日创建dev时的master快照作为共同祖先节点。此时Git会对比两组变更：

• 从共同祖先到master：仅包含4月30日的提交m2
• 从共同祖先到dev：仅包含5月5日cherry-pick过来的m1（注：cherry-pick会生成全新提交，哈希值和feature分支的原m1完全不同）

如果m1和m2属于同位置的替换式修改（比如两者修改了完全相同的代码行，内容为互斥的替换），Git的合并算法会判定这属于可自动合并的场景，直接采用master分支的m2内容覆盖dev中的m1，不会触发冲突提示。这种行为是Git默认递归合并策略的判定结果，只有当修改出现“交叉冲突”（比如同一行内部分内容被两边分别修改）时，才会要求人工介入。

复现失败的可能诱因 #

1. 提交内容差异：复现时的m1、m2修改的代码位置、内容细节和原场景不一致，比如原场景是整行替换，复现时改成了行内部分修改，这会触发Git的冲突检测机制；
2. Git版本差异：不同版本的Git合并算法有细节调整，部分旧版本对冲突的判定阈值更宽松，新版本可能会将原场景判定为冲突；
3. 操作步骤偏差：原场景中cherry-pickm1时可能存在隐藏的冲突解决、提交内容修改等操作，导致dev分支的提交状态和复现场景不一致；
4. 仓库配置差异：原仓库可能设置了自定义合并策略（如merge.theirs）或合并驱动，而复现仓库使用默认配置，导致合并行为不同。

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