合并

Merge

也常被叫作：合并分支合回主线把分支合进来

版本与协作通常止于「运行时」约 1 分钟读完

你可能会这么说

「把分支上做完的改动合回主线，两边变成一份代码。」

合并 Merge

把分支上做完的改动并回主线，两边变成一份代码。

合并（merge）就是把一条分支上做完的改动并回主线。分支是「工地」，主线是「已交付的房间」：活干完了、验收过了，把工地上的成果搬回主线。

合并前最重要的动作是先看清楚会带回来什么。让 AI 先跑 git diff main..分支名给你看：这次分支相对主线改了哪些文件。你确认范围没问题，再让它 git merge。这一步拦住绝大多数「合并完发现把不该带的也带回来了」的事故。

合并本身一般很顺。如果两边都改了同一个地方，Git 会停下来问你要答案——这就是合并冲突（merge conflict）。记住：冲突不是合并失败，是 Git 在尽职地问你。解决完冲突再提交，合并才算完成。

长什么样真实可交互，不是截图

分支改完→切回主线→git merge→改动进主线

git switch main
git merge 修登录页
git log --oneline

✓ 合并后：主线含分支全部改动

✕ 假合并：主线文件根本没变

合并的实质是「分支的改动进入主线历史，并出现在主线文件里」。如果主线的 log 和文件都没变化，那就不叫合并。

拆开看，里面有这几块

1
来源分支 Source branch
被合并的那条：改动从哪来。合并前它就是「待验收的活」。
2
目标分支 Target branch
合并进哪条，通常是 main。
3
合并提交 Merge commit
合并产生的新记录，记着「把谁合进了谁」。git log 里能看到。
4
冲突点 Conflict
两边改了同一处，Git 停下来等决策的地方。详见 merge-conflict 词条。

常见的有哪几种

快进合并Fast-forward

分支从主线拉出去后主线再没动过，合并只是把主线直接平移到分支位置，历史很干净。

用在：单人开发、主线没被其他人改动

普通合并Merge commit

两边都动过，Git 把两边的改动拼起来，产生一个合并提交记录。

用在：多人协作、主线有新提交

冲突合并Merge with conflict

两边改了同一处，需要人决策。

用在：两条线都动了同一个文件

容易搞混？这样区分

合并 ≠ 手动复制文件 Copy files manually

手动复制是覆盖：只有你复制过去的那边留下，另一边的改动直接没了。merge 是合并：Git 把两边都有的改动拼在一起，拼不拢才问你。判断方法：两边都改过同一个文件，手动复制后另一边的改动还在吗？

合并 ≠ 推送到远程 Push

推送（push）只是把分支上传到服务器，主线上没有任何变化；合并才是把改动真正并进主线。判断方法：合并后，主线的 git log 里有没有那条分支的提交？

看推送到远程

什么时候用得上

功能完成后合回主线

验收通过再合并。合并前先看 diff 确认范围，别合完才后悔。

合并前审查

让 AI 跑 git diff main..分支名 --stat，把「会带回来什么」列清楚再动手。

合并后验证

合并完打开关键文件确认改动在，再跑一遍程序确认没被合坏。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】把分支 [分支名] 的改动合并回主线 main，并验证合并结果
【范围】只做这次合并及合并后的验证，不改动合并范围之外的内容
【边界】
  - 合并前先 git switch main，再跑 git status 确认工作区干净
  - 合并前先跑 git diff main..分支名 --stat，把「这次会带进来哪些文件」列给我，我确认范围后再执行 git merge 分支名
  - 如果出现冲突，**停下来**，把冲突文件列给我，不要擅自选一边（按 merge-conflict 词条的处理流程走）
  - 合并完成后不要立刻删分支，等我确认合并结果
【交付】
  1. 合并前：git diff main..分支名 --stat 的改动清单
  2. 合并后：git log --oneline 最新几条 + 指出主线上哪些文件包含了分支的改动
  3. 确认分支是否可删除，给出命令 git branch -d 分支名，由我确认后再执行

「合并前先看 diff 确认范围」是这段的灵魂：AI 默认会直接 merge，带回来什么完全不受控。冲突时要停下来列出来、禁止擅自选边——这句话直接对接到 merge-conflict 词条的处理流程。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

合并后跑 git log --oneline，主线的历史里能看到分支的提交。
打开关键文件，确认分支上的改动真的出现在主线代码里，不是只在分支上。
跑一遍程序（或让 AI 启动开发服务器），确认合并后能正常起来，没有被合坏。
核对合并前看过的 diff：主线新增的内容和 diff 清单一致，没有夹带没见过的改动。

它常这么糊弄你

「合并完了」——但主线的 git log 里没有分支的提交，文件也没有变化。
「改动都带过来了」——打开文件一看，分支的改动根本不在主线里。
「很顺利，一次就合好了」——但合并时出现过冲突，被 AI 擅自选边解决，另一边的改动丢了。
「分支删掉了」——结果主线其实没合进去，分支一删，活全没了。

合并本身能验到「运行时」层：git log 和文件内容都是可观察的事实。「合并没引入新问题」要跑到真实用户路径（主路径层）才算彻底，所以本词条给到运行时，功能级验证交给联调验收。

考考你选一个你觉得对的

AI 说「分支已经合并到主线了」。哪条验证最直接？

想再深挖一点靠谱出处

git-merge（Git 官方文档）Git 官方文档 ↗关于合并拉取请求（About pull request merges）GitHub Docs ↗Git 分支 - 分支的新建与合并（Pro Git 中文书）Git 官方文档 ↗

# 合并 (Merge)

> 把分支上做完的改动并回主线，两边变成一份代码。

**你可能会这么说**：把分支上做完的改动合回主线，两边变成一份代码。

合并（merge）就是把一条分支上做完的改动并回主线。分支是「工地」，主线是「已交付的房间」：活干完了、验收过了，把工地上的成果搬回主线。 合并前最重要的动作是先看清楚会带回来什么。让 AI 先跑 git diff main..分支名 给你看：这次分支相对主线改了哪些文件。你确认范围没问题，再让它 git merge。这一步拦住绝大多数「合并完发现把不该带的也带回来了」的事故。 合并本身一般很顺。如果两边都改了同一个地方，Git 会停下来问你要答案——这就是合并冲突（merge conflict）。记住：冲突不是合并失败，是 Git 在尽职地问你。解决完冲突再提交，合并才算完成。

**也叫**：合并分支、合回主线、把分支合进来

## 你可以这样告诉 AI

```text
【任务】把分支 [分支名] 的改动合并回主线 main，并验证合并结果
【范围】只做这次合并及合并后的验证，不改动合并范围之外的内容
【边界】
  - 合并前先 git switch main，再跑 git status 确认工作区干净
  - 合并前先跑 git diff main..分支名 --stat，把「这次会带进来哪些文件」列给我，我确认范围后再执行 git merge 分支名
  - 如果出现冲突，**停下来**，把冲突文件列给我，不要擅自选一边（按 merge-conflict 词条的处理流程走）
  - 合并完成后不要立刻删分支，等我确认合并结果
【交付】
  1. 合并前：git diff main..分支名 --stat 的改动清单
  2. 合并后：git log --oneline 最新几条 + 指出主线上哪些文件包含了分支的改动
  3. 确认分支是否可删除，给出命令 git branch -d 分支名，由我确认后再执行
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 合并后跑 git log --oneline，主线的历史里能看到分支的提交。
- [ ] 打开关键文件，确认分支上的改动真的出现在主线代码里，不是只在分支上。
- [ ] 跑一遍程序（或让 AI 启动开发服务器），确认合并后能正常起来，没有被合坏。
- [ ] 核对合并前看过的 diff：主线新增的内容和 diff 清单一致，没有夹带没见过的改动。

常见糊弄：
- 「合并完了」——但主线的 git log 里没有分支的提交，文件也没有变化。
- 「改动都带过来了」——打开文件一看，分支的改动根本不在主线里。
- 「很顺利，一次就合好了」——但合并时出现过冲突，被 AI 擅自选边解决，另一边的改动丢了。
- 「分支删掉了」——结果主线其实没合进去，分支一删，活全没了。

来源：https://mickerbook.com/reference/t/merge/