在 Git 中发生代码冲突的本质原因，用一句话概括就是：

多条并行分支（历史线）基于同一个“共同祖先”，对代码库中“同一资源的相同位置”进行了不兼容的修改，导致 Git 的合并算法无法自动推断出应该保留哪一部分，必须依赖人工来做业务决策。

要深入理解这个本质，我们需要从 Git 的底层机制、算法逻辑以及团队协作三个层面来剖析：

一、 底层算法原因：三路合并（Three-Way Merge）的局限性

Git 在合并分支时，主要依赖“三路合并”算法。当你要把分支 B 合并到分支 A 时，Git 会寻找这三个点：

1. 当前提交（Local）：分支 A 的最新提交。
2. 目标提交（Remote/Incoming）：分支 B 的最新提交。
3. 共同祖先（Merge Base）：分支 A 和 B 分叉时的那个共同提交。

Git 的自动合并逻辑是这样的：

• 如果某一行代码在祖先中是 X，在 A 中变成了 Y，在 B 中依然是 X。Git 认为只有 A 做了修改，自动合并为 Y。
• 如果某一行代码在祖先中是 X，在 A 中依然是 X，在 B 中变成了 Z。Git 认为只有 B 做了修改，自动合并为 Z。

冲突爆发的条件：

• 如果某一行代码在祖先中是 X，在 A 中变成了 Y，在 B 中变成了 Z。
• 此时 Git 彻底懵了：“两个人都修改了同一处，且改成了不同的样子，到底谁的才是对的？”
• Git 作为一个纯粹的版本控制工具，不懂业务逻辑，为了防止破坏代码，它只能中止自动合并流程，抛出冲突（Conflict），把决定权交给人类。

二、 触发冲突的具体物理场景

在代码层面，冲突通常表现为以下几种物理形态：

1. 同文件、同位置的修改（最常见）
   • 开发者甲和开发者乙都修改了 login.js 文件的第 10 行。
   • 甲把变量名改成了 userName，乙把变量名改成了 userAccount。
2. 修改 vs 删除 (Modify/Delete Conflict)
   • 开发者甲在分支 A 中对 utils.js 增加了一个新函数。
   • 开发者乙在分支 B 中认为 utils.js 已经废弃，直接将其删除了。
   • 合并时 Git 不知道是应该恢复文件并保留修改，还是彻底删除。
3. 相邻行的上下文干扰
   • 即使甲修改了第 10 行，乙修改了第 11 行，但如果这两行的修改导致代码块的语法结构（如括号 {} 的闭合）发生歧义，Git 出于安全考虑也可能会报冲突。

三、 团队协作（工程化）原因

从更高的工程视角来看，Git 冲突的本质是团队协作中任务边界的重叠和信息同步的滞后：

1. 分支存活时间过长（长分支）
   • 某个特性分支开发了几个月都不和 main 分支同步。时间越长，main 分支上发生的改变就越多，与长分支底层的“共同祖先”差异就越大，合并时发生冲突的概率呈指数级上升。
2. 任务拆分不合理，缺乏隔离性
   • 项目管理上，让两个开发者同时去开发紧密耦合的同一个模块、同一个页面或同一个类的核心逻辑。
3. 大范围的代码重构或格式化
   • 一个人为了代码规范，用 Prettier 或 ESLint 全局格式化了整个项目的所有文件（改变了空格、换行）。
   • 另一个人在正常开发业务。
   • 两者一合并，几乎所有文件都会因为换行和空格的差异而爆发“灾难级”冲突。

总结

Git 冲突并不是 Git 的设计缺陷，相反，它是 Git 保护代码安全性的一种机制。它的本质是并行的历史线发生了业务逻辑上的碰撞。

解决冲突的过程，本质上就是人类开发者介入，告诉 Git：“在了解了这两人的修改意图后，最终的业务代码应该长这样。”