讲解
分支上的工作完成后，用 git merge 把它合回主线。流程固定：先切到「接收方」分支（通常是 main），再 git merge 功能分支名——把功能分支的提交并进来。方向一定要想清楚：merge 是把参数分支合进当前分支，不是反过来。
合并有两种形态。第一种是快进（fast-forward）：如果 main 在你岔出功能分支后没有新提交，Git 只需把 main 指针往前挪到功能分支的位置，历史是一条直线，不产生合并提交。第二种是三方合并（three-way merge）：main 和功能分支都有新提交，Git 找到两者的共同祖先，把两边的改动合在一起，生成一个特殊的「合并提交」（它有两个父提交）。git log --graph 里能看到清晰的分叉与汇合。想强制保留「这是一个功能分支合入」的记录，即使可以快进也可以用 git merge --no-ff 生成合并提交，团队里常这样干以便回溯功能边界。
顺利的话 merge 全自动完成；不顺利时会发生冲突——两边改了同一处，Git 不知道听谁的。冲突解决是下一章的主题。另外合并前记得确认当前分支：先 git branch 或 git status 看清自己站在哪，再决定 merge 谁。
示例
先演示快进合并：
git switch -c feature
echo "新功能" > feature.txt
git add feature.txt
git commit -qm "feat: 新功能"
git switch main
git merge feature --no-edit
git log --oneline
此时 main 没有新提交，merge 直接快进。再造一个需要真正合并的场景：
git switch -c release
echo "发布说明" > RELEASE.txt
git add RELEASE.txt
git commit -qm "chore: 发布说明"
git switch main
echo "main 上的工作" > main-work.txt
git add main-work.txt
git commit -qm "feat: main 上的工作"
git merge release --no-edit
git log --oneline --graph
两边都有新提交，merge 生成一个合并提交，--graph 输出里能看到分叉再汇合的结构。
常见坑
- 方向搞反：想「把功能合进 main」却在功能分支上 git merge main，结果把 main 的提交拉进了功能分支。虽然内容上殊途同归，但历史方向乱了就不好读，先切对分支。
- 合并前工作区不干净：未提交的改动可能和合并结果冲突，Git 会直接拒绝。先提交或 stash。
- 不知道什么时候用 --no-ff：快进让历史更简洁，--no-ff 保留功能边界便于整组回退，团队定一个约定然后遵守，别混用。
- 合并完不验证：合并成功不等于代码正确，跑一遍测试再推送，冲突解决处尤其值得多看一眼。
小结
merge 把指定分支合进当前分支；无分叉时快进，有分叉时生成合并提交；--no-ff 可以强制保留合并记录。下一章处理合并中最棘手的情况：冲突。