5. 合并与冲突

这是什么：合并（merge） = 把分支上的成果合回 main；两边改了同一处又改得不一样，就成了冲突。

为什么用：上一章你造出了好几条平行世界，可它们不能永远各活各的，迟早要收拢回主干。合得顺叫 merge，合不顺就撞上冲突——躲不掉，只能学会怎么解。

如何用：本章先看没有新提交的 fast-forward，再亲手制造一次冲突，按「看清标记 → 改内容 → add → commit」四步解决。

5.1 快进合并（fast-forward）

main 没有新提交、只是落后于分支时：

git switch main
git merge feat_readme

你会看到：

Updating a1b2c3d..e4f5g6h
Fast-forward
 readme.md | 1 +

「Fast-forward」= 仅把 main 的指针往前拨，零冲突。

5.2 真合并（三方合并）

两边各有提交时，Git 生成一个「合并提交」：

Merge made by the 'ort' strategy.

历史图（git lg）长出小叉：

*   e4f5g6 (main) Merge branch 'feat_x'
|\
| * c2d3e4 (feat_x) feat: xxx
|/
* a1b2c3 main 原先落点

5.3 冲突是怎么一场什么

同一处代码，两边都改了且改得不一样，Git 不敢替你做主：

<<<<<<< HEAD
M 就我在 main 的 IMPROVED 版本
=======
这里的 feat 分支的版本
>>>>>>> feat_readme

解决四步法：

# ① 看到 CONFLICT 报错（合并工具输出冲突文件清单）
git status

# ② 打开冲突文件，手工决定保留哪段（或融合两段），删掉 <<< >>> === 三个标记

# ③ 告诉 Git 冲突解决完
git add 冲突文件

# ④ 彻底结案
git commit        # 合并提交完成

心法：冲突不可怕，标志是界线，内容是你和同事各自真实目的。理解意图后融合，才是真解决——不是无脑二选一。

5.4 中途想放弃

git merge --abort      # 回到合并前的 main，生活继续

5.5 减少冲突的习惯

1. 小步快提交：改动范围小、周期短，冲突概率指数下降
2. 频繁同步 main：分支长了先 git merge main 吐一半自己消化
3. 分工资：同一文件尽量不同人同时改（分工讲清楚）

5.6 动手改

1. 两条分支都改 readme 同一行、都提交，merge 亲历一次冲突
2. 按四步法解决并完成合并提交
3. git merge --abort 玩一次「后悔药」

5.7 小结

• 无对抗 = Fast-forward；有分叉 = 三方 merge commit
• 冲突 = <<< >>> === 手术区：理解意图 → 融合 → add → commit
• 小步提交 + 常同主 分支，冲突从根本变少

下一章：远程仓库 🐸