冲突处理惯例专题

学完这篇你会掌握什么

• 理解 冲突处理惯例专题 的核心作用和适用场景
• 掌握 冲突处理惯例专题 的基本用法和常用参数
• 把冲突处理变成固定流程，减少临时操作带来的遗漏和误判。
• 理解 为什么冲突处理最怕"临场发挥" 相关的概念
• 掌握 1. 冲突出现后的第一步永远是先看状态 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

先想一个问题

你的团队在 Git 使用上积累了一些习惯，但你不确定这些习惯是否最优——或者你刚经历过一次因为 Git 操作不当造成的事故，想知道怎么避免下次再犯。

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

合并前（各自修改）

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 或提交

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

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• 提交信息规范约定
• 先 fetch 再同步
• 小步提交与主题分支整洁度