Git 冲突解决指南

引言

Git 是目前最主流的版本控制工具。在多人并发协作的团队中，当两个开发者同时修改了同一行代码，或者一个人重命名了一个文件而另一个人正在修改它时，Git 便会触发冲突（Conflicts）。如何从容、安全地解决冲突是每个开发人员的必备功底。

Git 在合并两个分支时，会寻找它们的“最近公共祖先节点（Merge Base）”，然后比对两个分支相对于祖先节点的修改差异。

执行 git merge 或 git rebase 后若遇到冲突，命令行会输出冲突文件名。你可以使用 git status 查询当前的冲突文件列表。

打开冲突文件，会看到 Git 自动注入的冲突标记：

<<<<<<< HEAD
console.log('Main Branch Content');
=======
console.log('Feature Branch Content');
>>>>>>> feature-branch

仔细沟通后，删除这些冲突指示符，修改为正确的业务逻辑代码，保存文件。最后执行：

git add file.js
git commit -m "chore: 解决 feature 分支合并冲突"

为了将冲突概率降到最低，团队应建立以下规范：

引言

冲突发生的底层原理

三方合并 (3-Way Merge)

Git 在合并两个分支时，会寻找它们的“最近公共祖先节点（Merge Base）”，然后比对两个分支相对于祖先节点的修改差异。

如果 A 分支只修改了第一行，B 分支没有动第一行，Git 会自动采纳 A 的修改并合并。

如果 A 和 B 都在第一行做出了不同的修改，Git 无法推断哪一方是正确的，便会将冲突行标出，把决定权交给开发人员。

冲突解决步骤

1. 定位冲突位置

执行 git merge 或 git rebase 后若遇到冲突，命令行会输出冲突文件名。你可以使用 git status 查询当前的冲突文件列表。

2. 理解冲突标记

打开冲突文件，会看到 Git 自动注入的冲突标记：

<<<<<<< HEAD console.log('Main Branch Content'); ======= console.log('Feature Branch Content'); >>>>>>> feature-branch

<<<<<<< HEAD 到 ======= 之间代表当前分支本地的修改。

======= 到 >>>>>>> feature-branch 之间代表待合并的分支引入的修改。

3. 手动合并与提交

仔细沟通后，删除这些冲突指示符，修改为正确的业务逻辑代码，保存文件。最后执行：

git add file.js git commit -m "chore: 解决 feature 分支合并冲突"

团队协作防灾规范

为了将冲突概率降到最低，团队应建立以下规范：

小步快跑：分支的生命周期切忌过长，频繁从主干分支 Pull 最新代码进行本地合并。

避免修改无关格式：禁止大面积运行格式化工具并提交，这会导致大面积的历史修改冲突。

合理分工：在重构公共类或底层逻辑前，提前同步团队成员，避免多人并发修改核心入口文件。