Git合并冲突分支时默认不高亮冲突，需用--edit的原因是什么？

核心原因：Git合并的自动解决逻辑与提交流程差异 #

你遇到的情况本质是Git在默认无编辑合并和**启用编辑模式（--edit）**时，对冲突的判定和处理逻辑完全不同：

1. 默认合并的自动解决逻辑 #

你用的ORT是Git当前默认的合并策略，它会尝试根据文件内容的上下文自动处理变更。看你的两个分支内容：

• master分支的greetings.txt：

  Hello 
  Hi
  Salut
  

• 目标分支的greetings.txt：

  Hi
  Hey
  Yo
  

Git判定这里是整段内容替换，而非局部行的冲突，所以直接用目标分支的内容完成了自动合并，生成了合并提交，自然不会提示冲突。

2. --edit参数的作用：强制触发严格冲突检查与手动提交流程 #

当你加上--edit参数时，Git会触发两个关键变化：

• 跳过部分自动解决逻辑，严格对比两个分支的内容差异，把这种整段替换的情况标记为内容冲突（CONFLICT (content)）
• 暂停合并流程，不会自动生成合并提交，而是让你手动解决冲突后再完成提交

你可以验证一下：默认合并后的greetings.txt内容就是目标分支的三行；而加--edit合并时，文件里会出现冲突标记：

<<<<<<< HEAD
Hello 
Hi
Salut
=======
Hi
Hey
Yo
>>>>>>> tampering

总结 #

Git默认合并时会优先尝试无歧义的自动解决，只有当它判定无法自动处理时才会标记冲突；而--edit参数会强制启用更严格的冲突检查，同时让你介入合并后的提交编辑，所以会显示出默认情况下被自动处理的"冲突"。

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