上游 · 理解本功能前需先掌握的（1）：
下游 · 依赖/承接本功能的（0）：
暂无下游（建议学完它再进阶）
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
分支上开发完的功能，最终要回到主线才算数。合并（merge）就是'把岔路接回大路'的操作：它会把你分支上改好的内容并入目标分支，让团队所有改动汇聚到一起。分支解决'分开做'，合并解决'汇回来'。
历史背景 · 它为什么诞生诞生于 2005
诞生Git合并（merge）与分支同生：合并是把分支变更整合回目标分支的核心操作，Git的三方合并（base/ours/theirs）与冲突检测机制使其在分布式场景下可靠。
功能介绍
合并（merge）把某个分支上的提交历史与改动并入另一个分支（通常是目标分支，如 main）。执行合并后，源分支的改动会成为目标分支历史的一部分，两边内容达成一致。合并过程中最常遇到的概念是冲突（conflict）：当两个分支修改了同一文件的同一位置、且 Git 无法判断该保留哪个时，就会产生冲突。冲突需要你手动解决：打开冲突文件，选择保留哪一版（或手动整合两版），然后再次提交完成合并。合并前建议先 git status 确认工作区干净，并确保目标分支是最新的。在 GitHub 上，分支合并通常通过 Pull Request（拉取请求）走审查流程完成，更正式也更安全。
核心术语
合并（merge）：把源分支的改动并入目标分支冲突（conflict）：双方改了同一处、需手动解决的合并状况目标分支：合并改动所进入的分支Pull Request：GitHub 上发起合并请求并附带审查的流程工作区干净（clean working tree）：没有未提交改动的状态
适用场景
- 当你完成功能分支开发、想把它合回 main 主线时
- 当合并报冲突、需要手动取舍两边的改动时
- 当你想用 Pull Request 走完'审查+合并'的完整流程时
- 当你需要把 main 的最新改动同步进自己的功能分支时
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 打开仓库 'Pull requests' 标签，点击 'New pull request' 发起合并请求
- 选择源分支与目标分支，创建 PR 并填写说明
- 在 PR 页面点击 'Merge pull request' 完成合并，再点击 'Delete branch' 清理分支
⌨️ 命令行 (进阶)
git checkout main # 先切到目标分支git pull origin main # 确保目标分支是最新的git merge feature-1 # 把 feature-1 合并进当前分支git branch -d feature-1 # 合并完成后删除已无用的功能分支
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 流程承接分支（Branch） | 分支开发完成后合并回目标分支 |
官方文档
小结
SUMMARY
合并把分支成果接回主线，冲突是合并时需手动协调的'两人同时改同一处'的情形。分支与合并是协作的基本功。下一步：学会用标签给历史打'里程碑'。