冲突处理惯例专题

为什么冲突处理最怕"临场发挥"

合并前（各自修改）

main

ABC

feature

BDE

标准流程：识别 → 理解 → 沟通 → 解决 → 验证

解决冲突后

main

ABCM

feature

BDEM

Git 冲突真正可怕的地方，通常不是命令本身，而是人一着急就开始乱试：先改文件，再跑命令，最后连自己现在是在 merge 还是 rebase 都说不清。
所以更稳的做法不是背更多命令，而是把冲突处理固定成一个重复流程。

1. 冲突出现后的第一步永远是先看状态

第一反应先执行：

git status

它会告诉你：

• 当前处于 merge 还是 rebase
• 哪些文件冲突了
• 下一步 Git 期待你做什么

这一步的价值在于先建立上下文，而不是直接冲进去编辑文件。

2. 解决冲突时不要只盯着标记

很多人看到 <<<<<<<、=======、>>>>>>> 就开始删标记，但真正要解决的是“哪一侧逻辑应该保留、怎么整合才符合当前目标”。

更稳的顺序通常是：

1. 理解冲突两侧各自代表什么
2. 决定保留谁、合并谁、重写谁
3. 再手动清理冲突标记
4. 完成后重新运行测试或关键命令

3. 冲突解决完成并不等于流程结束

很多错误都发生在“文件能保存了”之后。解决完以后至少要再做三件事：

git add <resolved-files>
git status

然后：

• merge 场景执行正常提交或继续流程
• rebase 场景执行 git rebase --continue

如果这是关键逻辑改动，还应该重新跑最小验证。

4. 什么时候应该中止，而不是继续硬顶

以下情况最好先停：

• 你已经看不懂两侧逻辑分别在干什么
• 一次冲突牵出了大量无关文件
• 你不确定当前操作是在 merge、rebase 还是 cherry-pick
• 你越改越像“先凑出能过的文件再说”

这时更保守的做法往往是：

• git merge --abort
• git rebase --abort

先回到清晰状态，再重新判断。

5. 一个团队可复用的冲突处理流程

可以把惯例收成这五步：

1. 先 git status
2. 先理解冲突来源，再改文件
3. 解决后清掉所有冲突标记
4. 重新验证关键逻辑
5. 最后再 continue 或提交

把这五步固定下来，冲突就会从“意外事故”变成“可重复处理的流程问题”。