Git 集成实战完全指南（四）：Git 冲突解决与合并策略-育师

1. 多人协作里，冲突到底卡在哪一步

只要你参与过三人以上的 Git 协作，大概率经历过这种时刻：本地改完准备推，git pull一执行，终端刷出一片CONFLICT (content): Merge conflict in ...，然后你盯着文件里那几行<<<<<<<、=======、>>>>>>>发呆，不知道哪边该留、哪边该删。更麻烦的是，冲突往往不止一个文件，改完一个还有下一个，最后干脆git merge --abort重来。

这篇聚焦的就是这个场景：多人协作中 Git 合并冲突的定位与解决流程。我会把冲突标记怎么读、手动合并怎么下手、合并工具怎么选、回滚怎么做，拆成能直接复制的步骤。同时给出一份.gitconfig冲突处理配置，配合分步验证命令，让团队在真实分支合并里稳定落地。适合已经会用git add、git commit、git push，但一遇到冲突就想重开分支的开发者。

需要说明的是，冲突本身不是错误，它是 Git 在告诉你「这两处改动它不敢替你决定」。理解这一点，后面的操作就顺了。

2. 前置准备：把冲突处理环境配好

在动手解决冲突之前，先把工具链理顺。这里不涉及任何网络加速类工具，全部是 Git 自带能力加一个可视化 diff 工具。

2.1 确认 Git 版本与基础信息

先确认版本，低于 2.30 的建议升级，因为merge.conflictStyle的zdiff3模式在较新版本才稳定：

git --version git config --global user.name "你的名字" git config --global user.email "you@example.com"

2.2 配置冲突显示风格

默认的冲突标记只有<<<<<<<和>>>>>>>，看不出共同祖先长什么样。开启zdiff3后，会多出一段|||||||显示原始版本，判断起来清楚很多：

git config --global merge.conflictStyle zdiff3

2.3 配置合并工具与默认策略

选一个可视化工具，Linux/macOS 常用meld，Windows 常用Beyond Compare或 VS Code 内置的合并编辑器。下面以 VS Code 为例：

git config --global merge.tool vscode git config --global mergetool.vscode.cmd 'code --wait --merge $REMOTE $LOCAL $BASE $MERGED' git config --global mergetool.keepBackup false

keepBackup false很关键，否则每次解决冲突都会留下.orig备份文件，容易误提交。

2.4 一份可直接复制的 .gitconfig 片段

把下面这段追加到~/.gitconfig，团队可以统一：

[merge] conflictStyle = zdiff3 tool = vscode [mergetool] prompt = false keepBackup = false [mergetool "vscode"] cmd = code --wait --merge $REMOTE $LOCAL $BASE $MERGED [diff] algorithm = histogram [rerere] enabled = true autoupdate = true

其中rerere（reuse recorded resolution）是很多人忽略的功能：它会记录你解决过的冲突，下次遇到相同冲突自动套用。多人长期协作同一模块时，能省下大量重复劳动。

注意：rerere记录的是「冲突片段到解决结果」的映射，如果团队对同一段代码反复产生相同冲突，开启它收益明显；但不要把它当成免检机制，自动套用后仍要跑测试。

3. 可复制配置：冲突定位与解决全流程

配置好之后，进入实际操作。假设当前在feature/user-search分支，要合并进develop。

3.1 合并前预检，先知道会不会冲突

不要直接git merge然后被一堆冲突淹没。先做一次「试合并」，看哪些文件会冲突：

git fetch origin git checkout feature/user-search git merge --no-commit --no-ff origin/develop git diff --name-only --diff-filter=U git merge --abort

--no-commit --no-ff表示即使能快进也强制产生一次合并提交，但不真正提交；--diff-filter=U只列出处于 unmerged 状态的文件。输出就是预计冲突的文件清单。确认完用git merge --abort回到干净状态。

3.2 读懂冲突标记

真正合并后，冲突文件长这样：

<<<<<<< HEAD const users = await userService.getList(params) ||||||| merged common ancestors const users = await userService.fetchList(params) ======= const users = await userService.searchUsers(params) >>>>>>> feature/user-search

三段含义：HEAD是当前分支（你所在分支）的版本，|||||||是共同祖先版本，=======之后是待合并分支的版本。有了祖先版本，你就能判断两边各自改了什么，而不是盲选。

3.3 手动合并的三种决策

面对一个冲突块，只有三种结果：留 HEAD、留对方、或者两者融合。判断依据是「祖先版本到两边各自的变化」：

情况	祖先	HEAD	对方	建议
改同一行不同意图	A	B	C	融合，通常两者都要
一方删除一方修改	A	删除	C	确认删除意图，必要时移植修改
格式化 vs 逻辑改动	A	仅格式	逻辑	保留逻辑，重跑格式化
双方新增不同内容	无	新增 X	新增 Y	两者都保留

融合时把标记行全部删掉，只留最终代码。比如上面那段，如果两个函数功能不同，就都保留：

const users = await userService.getList(params) const searchResult = await userService.searchUsers(keyword)

3.4 用 mergetool 处理复杂冲突

冲突块多、跨文件时，命令行逐块改效率低。直接调起配置好的工具：

git mergetool

VS Code 会以三栏或四栏形式展示 LOCAL、BASE、REMOTE、MERGED，点选即可。处理完保存关闭，Git 自动标记该文件已解决。如果某个文件你确定整份采用某一方，可以跳过工具：

git checkout --ours src/config/production.json git checkout --theirs src/views/UserList.vue git add src/config/production.json src/views/UserList.vue

--ours是当前分支，--theirs是待合并分支，别记反。

3.5 解决后验证与提交

所有冲突文件git add之后，先别急着 commit，跑一遍验证：

git status npx tsc --noEmit npx eslint src/ pnpm test

四项都过再提交：

git commit -m "merge: 合并 develop 到 feature/user-search，解决 user.ts 与 UserList.vue 冲突"

3.6 回滚策略

解决到一半发现方向错了，分几种情况回滚：

# 还没 commit，想放弃整个合并 git merge --abort # 已经 commit，想撤销这次合并提交 git reset --hard ORIG_HEAD # 只想撤销某个文件的解决结果，重新来 git checkout -m src/api/user.ts

ORIG_HEAD是 Git 在执行 merge、rebase 等操作前自动记录的指针，比记 commit hash 方便。git checkout -m会把文件恢复成带冲突标记的状态，让你重新解决。

4. 验证请求：确认冲突真的解决干净

解决冲突最怕「以为解决了」。下面这套检查能兜住大部分遗漏。

4.1 确认没有残留冲突标记

git diff --check grep -rn "<<<<<<<\|>>>>>>>\|=======" src/ --include="*.ts" --include="*.vue"

git diff --check会报出空白错误和冲突标记残留。grep 是双保险，尤其当冲突标记被误当成普通文本提交时。

4.2 确认合并结果符合预期

git log --oneline --graph -10 git diff origin/develop...HEAD --stat

第一行看合并拓扑是否正常，第二行看相对 develop 的改动范围是否合理。如果 diff 里出现大量你没动过的文件，说明合并时可能误引入了对方的中间状态。

4.3 跑一次完整构建

pnpm build

编译通过不代表逻辑正确，但编译不过一定有问题。构建产物大小如果比合并前暴涨，也要留意是不是重复引入了依赖。

4.4 用 rerere 验证自动复用

如果你开启了rerere，第二次遇到相同冲突时：

git rerere status git rerere diff

rerere status列出它准备自动解决的文件，rerere diff展示它打算怎么解决。确认无误再git add。这一步相当于让 Git 帮你预演一遍。

5. 本篇常见错排查

实际操作中，下面几个坑出现频率最高。

5.1 冲突标记被提交进仓库

现象：代码里出现<<<<<<<，运行报语法错误。原因通常是git add时没检查，或者用了git commit -a一把梭。排查：

git log -S "<<<<<<<" --oneline

找到引入的提交，用git revert或修正后重新提交。预防手段就是上面 4.1 的git diff --check。

5.2 ours / theirs 记反

git checkout --ours在 merge 时指当前分支，但在 rebase 时语义会反过来——rebase 的--ours是「正在被 rebase 到的目标分支」。这是最容易翻车的地方。建议 rebase 时不要用--ours/--theirs，改用git checkout -m重新手动解决，或者先git rebase --abort改用 merge。

5.3 合并后测试全挂但代码看着没错

多半是「语义冲突」：两边代码单独都对，合在一起逻辑冲突。比如 A 分支把函数改成异步，B 分支在同步上下文里调它。这类冲突 Git 检测不到，只能靠测试。所以 3.5 的测试步骤不能省。

5.4 mergetool 打开是空白

通常是mergetool.vscode.cmd里的$BASE变量在某些 Git 版本下为空导致。可以先确认：

git config --get mergetool.vscode.cmd

如果工具对空 BASE 不友好，把命令里的$BASE去掉，改成三栏模式即可。

5.5 rerere 自动解决错了

rerere是「记录即复用」，如果第一次解决时就是错的，后面会一直错。发现后：

git rerere forget src/api/user.ts

清掉该文件的记录，重新手动解决一次，让它重新学习。

5.6 大文件冲突看不清

几千行的配置文件冲突，直接看标记会晕。用：

git diff --cc src/config/production.json

--cc是 combined diff 模式，只显示冲突区域，不刷全文件。配合zdiff3的祖先段，定位很快。

6. 把冲突处理沉淀成团队习惯

冲突解决本身是技术活，但减少冲突是流程活。几个实测有效的做法：每天开工先git fetch && git rebase origin/develop，让小冲突当天消化；一个 PR 只做一件事，避免大杂烩；对高频共享文件（比如http.ts、BasicLayout.vue）约定改动前在群里说一声。

如果你在团队里推广这套流程，可以把第 2.4 节的.gitconfig片段放进仓库的docs/或 onboarding 文档，新人 clone 后照着配一次。冲突处理工具链统一了，review 时也少很多扯皮。

对于需要长期在编码环节和 Git 打交道的场景，比如频繁 rebase、批量解决冲突、生成合并提交信息，可以了解一下 TaoToken 的 Coding Plan（https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding_plan），它面向的就是这类持续编码工作流。如果只是想先验证某个模型对冲突代码的理解能力，可以直接在模型对话页（https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model_chat）贴一段冲突代码试试。接入自己的脚本或 CI 时，API Key 在控制台（https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api_keys）生成，接口地址是 https://taotoken.net/api，接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc。用 Claude Code 做 Git 操作的，参考 https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=claude_code。

下一篇会讲 Git Blame 与历史追踪，也就是冲突解决之后，怎么追溯某一行代码是谁、在哪次提交里改的。