报警的边界：同一行才算撞车

Git 的合并以行为单位进行比对。两个补丁一旦触及相同行，工具便将其标记为冲突、交由开发者手动裁决——这是它识别“撞车”的唯一手段。它并不理解代码的语义：两项各自成立、放在一起才出问题的改动，只要落在不同的行上，就能双双顺利通过合并。

这也意味着，两个工单给出同一功能的不同实现，或是在互不相干的位置改动了彼此依赖的逻辑，Git 同样不会察觉。文本层面的“同行相撞”会触发报警，语义层面的“各行其是”则一路绿灯。

第二道闸：评审，以及评审者的记忆

在工具失效的地方，代码评审成为事实上的最后防线。但这条防线的强度完全取决于人：只有当评审者对两张工单都熟悉——知道各自在做什么、改动之间存在何种牵连——才可能认出这是同一件事的两种写法，或是迟早会互相干扰的两处修改。若评审者只接触过其中一张工单，重复劳动与逻辑冲突便会随合并一同进入主干。

换句话说，冲突检测止步于文本行，语义层面的把关被交给了记忆与上下文：谁同时见过这两张工单，谁才守得住这道闸。

Git 只在补丁触及同一行时才提示冲突，评审能否拦下问题取决于评审者是否熟悉两张工单——这一结论基本属实。