Git 进阶指南：3 种常见冲突解决姿势与代码差异对比（Diff）工作流

1. 为什么代码冲突总让人胆战心惊？#

在多人敏捷团队中，合并分支时终端里跳出的红字往往是开发者的噩梦：

bash
CONFLICT (content): Merge conflict in src/services/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

很多人下意识地全盘保留“我的更改（Ours）”或“他们的更改（Theirs）”，稍有不慎就会把同事写了两天的核心功能悄悄覆盖掉。

---

2. Git 是如何发现冲突的？（Three-way Merge 算法机理）#

Git 的合并算法并非简单地比对两个分支的最新代码，而是基于三方比对（Three-way merge）：

BASE（公共祖先节点）：两个分支在分叉时的最后一次共同提交；

OURS（当前分支最新提交）；

THEIRS（目标分支最新提交）。

判定规则：

如果一段代码在 BASE 基础上，只有某一方做了修改，Git 会自动采纳该修改；

只有当同一行代码在两个分支都被修改，且修改内容不一致时，Git 才会判定为冲突，交由人工裁决！

---

3. 高效解决冲突的三种姿势#

姿势一：借助专业可视化 Diff 工具#

很多时候终端里的 <<<<<<< HEAD 和 >>>>>>> 标示会打乱代码缩进，尤其是括号成对复杂的代码。 此时可直接复制两侧变动至站内的 [文本与代码对比工具 (Diff)](/tools/diff)：

开启 分栏对比（Side-by-Side） 视图；

开启 字符级高亮（Char-level Diff）；

左右一键对比增删行与修改比例，极大降低人工看错漏合的风险。

姿势二：优先利用 rebase 保持线性 Git 历史#

在合入主干（main/dev）前，推荐先在本地特性分支执行：

bash
git fetch origin
git rebase origin/main

这样会将主干的最新提交作为你本地提交的基底，冲突将在提交发生时分段解决，而不是在最后的 merge commit 中积攒成一个巨大的混乱炸弹。