我记得很清楚，某个周五的下午，我在一个仓库里把做了将近两周的大功能分支往主干上合。命令敲下去，Git 只回了一行字：
Fast-forward当时我还觉得挺顺利，没多想就推上去了。结果两天后另一位同事在 code review 的时候问我：这个功能你们写了十几个提交，怎么主干上看不到任何痕迹？我打开 log 一看，所有提交确实都在，但已经排成一条直线，压根分不清哪些提交属于这次功能。
那次之后我才认真把Fast-Forward和No-FF的区别彻底捋了一遍。后来发现团队里搞不清这俩概念的人非常多，而且大家踩的坑翻来覆去就那么几个。这篇文章就围绕这两个合并模式展开，讲清楚它们各自何时触发、底层做了什么、各自有什么代价，再把最容易被忽略的回滚问题一并说透。适合刚开始系统学习 Git 的开发者，也适合那些 merge 用了好几年、但从来没分清过这两种路径的老司机。
1. Fast-Forward 并不神秘：一次合并背后的指针平移
1.1 分支到底是个什么东西
很多人对分支的理解停留在"分支是一段独立的代码"这种层面，这个理解不能算错，但会妨碍你搞懂合并的底层行为。
其实在 Git 里，分支本质上只是一个指针——一个 41 字节左右的文本文件，里面存着一个 commit 的 SHA-1 值。真正的代码内容全部挂在 commit 组成的提交链上，而分支指针只是指向这条链的某个位置。
你用git branch feature创建分支，Git 做的事就是拿着当前所在分支的 commit 值，去复制一个新的指针文件，仅此而已。切分支是移动指针，提交代码是让当前指针指向一个新的 commit，然后新 commit 的 parent 字段指向原来的 commit。
整个过程可以类比成看书时夹书签：书签只是夹在某一页，看到哪一页内容，取决于书签夹在哪。Git 的分支指针就是那个书签，提交链就是书本身的内容。
所以你在想"合并分支"的时候，脑子里最好自动翻译成一句话：我要把某个指针，移动到另一个指针所指的提交链位置上去。
1.2 满足什么条件才会走 Fast-Forward
Fast-Forward 的触发条件，从定义上看其实极其苛刻：
当前分支的 HEAD 所在位置，正好是被合并分支的祖先。
用大白话说就是：你站在 master 上，master 指向的那个 commit，可以通过 parent 指针一路找到 feature 分支的 HEAD。此时 Git 要做的事就是把 master 指针直接往前挪到 feature 的 HEAD 上。它不需要生成新的快照，不需要做三方合并，不需要比较差异，只是纯粹地把指针从位置 A 移到位置 B。
你可以用一个最小的场景复现一下：
# 1. 从最新 master 切出功能分支 git checkout master git checkout -b feature # 2. 在功能分支上提交三次 echo "a" > a.txt && git add a.txt && git commit -m "feat: a" echo "b" > b.txt && git add b.txt && git commit -m "feat: b" echo "c" > c.txt && git add c.txt && git commit -m "feat: c" # 3. 切回 master 并合并 feature git checkout master git merge feature第三步输入git merge feature之后，输出就是那种非常简短的一行Fast-forward。整次合并没有产生任何新的 commit，master 只是从原来的位置直接跳到了 feature 的 HEAD。
动手试的时候，你可以用git log --oneline --graph看看，主干的提交历史会是一条笔直的线，没有任何分叉的痕迹。很多人第一次看到这种情况，以为 Git 出了 bug 把提交丢了，其实不是，所有提交都在，只是它们被摊平了。
1.3 为什么同一个 merge 命令，有时 FF 有时生成 merge commit
这是最容易让人困惑的地方：同样一条git merge feature，为什么有时候输出Fast-forward，有时候却弹出一个 commit message 编辑框让你写合并说明？
原因很简单：Fast-Forward 只是 Git 默认优先尝试的路径，不是强制路径。只有当"当前分支 HEAD 是目标分支祖先"这个条件成立时，Git 才允许走快进；一旦 master 上也出现了自己的新提交，两个分支从某个共同祖先处分叉，那么快进条件就不再成立，Git 会退回去做真正的三方合并，生成一个带有双亲的 merge commit。
判断现在能不能快进，不用靠猜，有现成的命令：
# 返回 0 说明 master 是 feature 的祖先，可以快进 git merge-base --is-ancestor master feature # 返回 1 说明两个分支已经分叉，不能快进还可以配合这个命令看两个分支相差的提交：
git rev-list master..feature --oneline上面这个命令会列出 feature 上有、而 master 上没有的提交。如果列出来的一串提交最终以 master 的 HEAD 为起点，说明可以快进；如果中途出现了分叉入口，那就不行。
这种"看起来像是同一个命令，但结果不同"的现象，本质上不是 Git 随机抽风，而是它根据提交链拓扑自动做了决策。理解了这个前提，后面看--no-ff时思路就顺了。
2. --no-ff 强制合并：用双亲节点给功能画上边界
2.1 --no-ff 生成的 merge commit 长什么样
--no-ff的全称是--no-fast-forward，它的作用一句话可以概括：就算满足快进条件，也强制生成一个新的 merge commit。
很多人第一次听说这个选项时很不理解：明明可以直接往前走，为什么非要弄出一个多余的提交来？这不是污染历史吗？
要回答这个问题，得先看看 merge commit 到底记录了什么。用git cat-file -p <merge-commit-sha>看某个 merge commit 的内部结构，会看到这样的输出：
tree 2d3f5a1b... parent 8d4e7f3c... # 第一个父提交：合并时你所在的分支 parent 9a2c1b6d... # 第二个父提交：被合并进来的分支 author 某开发者 <dev@example.com> 1678930123 +0000 committer 某开发者 <dev@example.com> 1678930123 +0000 Merge branch 'feature' into master普通提交只有一个 parent，而 merge commit 有两个 parent。这两个 parent 的意义非常直观：一个是合并前 master 所在的位置，一个是 feature 分支合入的位置。Git 通过这两个指针，把"这件事发生在哪两个顶点之间"完完整整地记了下来。
所以你用--no-ff合并不只是多了一个提交，而是给这次功能合并钉了一颗钉子，将来无论过了多久，你都能准确说出这个功能是从哪个点长到哪个点的。
2.2 必须用 no-ff 的实际场景
我自己总结下来，下面这几类场景基本绕不开--no-ff：
第一类是主干上需要呈现每次"合入"事件。比如发布流程走主干，每次发布后要快速定位"这个版本里包含哪几个功能"。如果主干上是清一色没有 merge 节点的直线提交，你只能靠 commit message 去猜哪些提交是一组功能；但如果你每个功能合入主干都带一个 merge commit，直接git log --first-parent --merges就能列出所有功能合入事件，一目了然。
第二类是代码评审以合并记录为单位。有些技术团队 review 代码时，习惯看主干上的 merge commit 而不是所有零散提交。merge commit 本身就是一个可 diff 的单元，它可以完整展示"这次合并整体上带来了哪些变化"，评审效率会提升很多。
第三类是发布分支与功能分支并行维护。我在某个项目里见过这种情况：release 分支是长期存在的，会同时接收多个 feature 分支的合并。如果在这些合并里不加--no-ff，当 feature 基于旧的主干创建时，每次都不可避免地会产生 merge commit；但如果某个 feature 碰巧基于最新 release 创建，它合并回来时就会走 FF，历史中有的功能有 merge 节点、有的没有，规则混乱，回溯时非常痛苦。统一用--no-ff至少能让所有功能都以同样的形态存在于历史里。
2.3 no-ff 的代价和补救手段
当然不能只说好处。--no-ff最大的代价在于懒人视角下的"乱"：历史不再是一条直线，会出现很多分叉，直接看git log --oneline会显得信息量过大。
但这个问题有一个非常成熟的补救工具，就是--first-parent。它只沿着每个 merge commit 的第一个父提交方向走，忽略被合并进来的分支内部的细碎提交。用它来查看主干脉络时，历史会变得非常干净：
git log --first-parent --graph --oneline master输出看起来就像一条串着多个合并节点的线，每个合并节点后面跟着一句Merge branch 'xxx'。想知道某个功能内部到底改了什么，再顺着第二个父提交去展开，也就是git log master^2。
说实话，在我接触过的团队里，真正严格按照--no-ff来维护历史的仓库，配合--first-parent看主干历史，体验通常反而比一大坨无脑快进的历史舒服得多。
3. squash 与 no-ff 混在一起用，迟早要踩 revert 的坑
3.1 squash 不是 no-ff 的简化版
网上不少文章把git merge --squash和git merge --no-ff放在一起说，给人一种"两者差不多，只是 squash 更简洁"的印象。这个认知真的会埋雷，它们俩在机制上差得很远。
--squash做的事是：把被合并分支上的所有改动打包成一个全新的提交，放到当前分支上。注意三个关键词：
- 打包：feature 上的 A1、A2、A3 三个提交，对应改动全部揉进一个 S 提交里。
- 全新：S 的内容是从工作区重新生成的快照，不是对 A1、A2、A3 的引用。
- 没有父关联：S 只有一个 parent，指向合并当前所在分支的 HEAD，不会指向 feature 的任何提交。
对比一下：
| 合并方式 | feature 上的提交是否保留 | 是否产生 merge commit | 合并结果与原分支的关联 |
|---|---|---|---|
| 默认 merge（可以 FF 时） | 是，全部保留 | 可能不产生 | 没有额外的指针关联 |
| merge --no-ff | 是，全部保留 | 总是产生，带双亲 | 通过 merge commit 关联 |
| merge --squash | 否，被压缩成一个新提交 | 不产生 | 完全没有关联 |
也就是说，--no-ff里那个 merge commit 的第二个 parent 直接把两条历史线接在了一起；而--squash只是把改动"复制"到当前分支，历史线上没有留下任何指向原分支的痕迹。
3.2 什么时候用 squash 才是合理的
说这么多不是要全盘否定 squash。它有自己的主场：
- 你维护的是对外开源仓库，希望 PR 合并后主干上只保留一条简洁提交记录；
- 功能分支上的提交非常碎，比如 "fix typo"、"wip"、"test"，你想在合入主干时梳理成一条语义清晰的提交；
- 自己本地做实验，分支只是临时容器，不需要追溯原始提交。
在这些场景下，squash 是很好的整理工具。但请记住它的前提：你合入之后基本不会再去追溯原分支的内部演变。
一旦你需要面向原分支做二次开发、反复回滚、长期维护，squash 就会开始给你找麻烦。
3.3 一个让我印象深刻的复盘
之前和某同事一起维护一个项目，他对 squash 有执念，总觉得 merge commit 是噪音，所以往 release 分支上交功能时全部用git merge --squash。
平时确实很清爽，直到有一次线上出问题，需要把某个功能整个退回。他执行了：
git revert <squash-提交的sha>回滚的那一刻看似正常，但随后更麻烦的事发生了：那个功能后续发布了修复版，修复分支被再次合入 release，结果之前 revert 掉的代码原封不动地又回来了。
原因就是他用的 squash 合并根本没有建立与原分支的父关联。后续合入时，Git 把 feature 分支上的全部改动当作新的变更重新应用了一遍，之前 revert 生成的补丁在那一刻完全失效。
那次事故之后，我在团队里定的规矩很简单：共享分支上合入功能，一律--no-ff，除非你确认这个分支将来彻底废弃不再用了，才允许 squash。这个规则在我接手过的多个仓库里都被证明是值得的。
4. 合并后的回滚才是重灾区：revert 双亲提交与"复活"问题
4.1 revert merge commit 为什么要指定 -m
很多人平时回滚普通提交习惯了，一条git revert <sha>走天下。但是当他要回滚一个 merge commit 时，Git 会直接甩一个报错：
error: commit <sha> is a merge but no -m option was given这个报错我第一次见时也愣了一下，后来想想就明白了。普通 commit 只有一个 parent，它的 diff 是相对唯一基准算出来的；而 merge commit 有两个 parent，针对两个父提交分别计算出来的 diff 完全不同。Git 不可能在没有上下文的情况下猜你到底想撤销哪一侧，所以必须用-m指定保留哪一条分支线。
最常用的写法是：
# 保留第一个父提交（即合并时所在的主干），丢弃被合并分支带来的改动 git revert -m 1 <merge-commit-sha>-m 1的含义是"在第一个父提交的基础上，反向应用整个 merge 引入的差异"，效果等价于撤销这一次合并事件，但不会动 feature 分支本身。-m 2则反过来，保留被合并分支的内容，在某些特殊场景（比如你想以被合并分支为基准清理主线）会用到，日常绝大部分回滚都是-m 1。
4.2 为什么 revert 之后功能会"复活"
这个坑是最隐蔽的，也是最容易导致线上事故的。先说结论：
如果你 revert 了一个 merge commit，之后又把原功能分支重新合入，先前被 revert 掉的代码几乎必然会全部复活。
原因要从 merge 的公共祖先说起。假设 feature 从主干点 C0 分出，提交了 A1、A2、A3，主干用--no-ff合并产生 M1，之后你用git revert -m 1 M1生成了 R1。此时主干 HEAD 指向 R1，源文件里已经没有功能代码了。
然后你在这个功能里修了个 bug，继续提交 A4，再次执行git merge feature。Git 在做这次合并时，会去寻找主干与 feature 的公共祖先。问题是，这个公共祖先并不是 R1——因为 R1 只是主干上的一条新提交，它没有与 feature 建立任何关联。Git 找到的公共祖先仍然是最初的 C0。于是 feature 相对 C0 的全部改动（A1 到 A4）都会作为新变更合入主干，R1 里撤销过的那部分东西自然重新出现了。
这不是 Git 的 bug，而是三方合并机制下的自然结果。Git 不记得"你之前撤销过某个功能"，它只负责比较当前两份快照与共同祖先的差异。
应对方法也很明确：
- 不要直接复用被 revert 过的旧分支去修复。正确做法是从 revert 之后的最新主干重新切一个新的修复分支，在新分支上重新实现或恢复功能，再合并回来。
- 如果旧分支上还积累了其他有用的修复，需要十分小心地把它们挑出来，用
cherry-pick而不是整体 merge。 - 团队里一旦执行了
revert -m 1，应当马上同步所有相关的开发者，避免大家继续在旧分支上开发而不知情。
4.3 在已快进的历史上回滚一个功能，只会更被动
前面说的回滚问题，前提是历史里至少有一个 merge commit 可以当作"把手"。如果你当初用的是 FF，那么一个功能的多个提交已经被摊平进主干，连这个把手都没有。
此时想回滚一个功能，你只能手动筛选出这个功能涉及的每一个提交，逐个执行git revert。如果这些提交之间还有依赖关系，比如后面的提交被前面某个中间状态影响，Git 甚至会拒绝直接 revert，要求你先解决冲突。这一套下来既费时又容易遗漏。
更糟糕的是，如果功能分支在 FF 合入后又被别的分支引用，做任何改写历史的操作都会波及到其他开发者。到了这一步，基本只能靠人肉修复代码来收场。
所以"合并前想清楚，合并主线务必留 merge 节点"这句话，真不是洁癖，是给自己留退路。
5. 把合并策略写进团队规范：命令、配置与检查脚本
5.1 按分支类型选策略的对照表
说了这么多机制，落回日常就是选型问题。我目前比较推荐的决策表长这样：
| 场景 | 推荐命令 | 理由 |
|---|---|---|
| 本地临时分支合入自己仓库 | 默认 merge，允许 FF | 快速简单，不需要额外信息 |
| 功能分支合入共享主干 | git merge --no-ff feature | 保留功能边界，方便 review 与回滚 |
| 合并 PR 时希望主干只保留一个提交 | git merge --squash feature | 历史清爽，但原分支不再追溯 |
| 只想验证分支能否干净合入 | git merge --ff-only feature | 宁可报错，也不生成意外的 merge 节点 |
| 团队用 rebase 流维护非线性历史 | rebase 到最新主干后 FF 合入 | 保持直线，但是要警惕回滚问题 |
这个表不是死的。你完全可以根据自己团队的节奏调整，但有一个原则我建议无论如何都要坚持：共享主干上的功能合入，要么有 merge 节点，要么坚决保证合入后不会再回头处理旧分支的回滚问题。两者至少占一样。
5.2 把命令变成配置，减少心智负担
与其每次合并时手动敲--no-ff，不如把这些选项固化到配置里，降低团队成员的认知负担。
# 全局让所有 merge 都默认采用 no-ff（慎用，影响你操作所有仓库） git config --global merge.ff false # 更推荐的做法：只对某个仓库的主干分支强制 no-ff git config branch.main.mergeoptions "--no-ff" # 让 pull 不做意外的快进合并，宁可失败 git config --global pull.ff only需要注意，merge.ff false是全局配置，它会影响你电脑上所有仓库的 merge 行为。如果你同时维护开源项目和内部项目，这个设置可能会让开源仓库的历史变得不是你期待的形态。更精细的做法是只给特定仓库配置，或者直接用第 5.3 节的别名方案。
还有一点容易忽略：这些配置只管你本地的 Git 行为。推送到远端之后，如果你用的是支持 Merge Request / Pull Request 的平台，那么平台上的合入方式另有一套策略，通常是 "Create a merge commit"、"Squash commits"、"Rebase and merge" 三选一。团队规范最好同时在 Git 配置、平台设置、开发文档三个层面保持一致，否则就会出现本地是 no-ff、平台上一键 squash 的分裂状态。
5.3 用别名和检查脚本把规范固化
配置弄好之后，日常使用再配两个别名，基本就不会敲错了：
git config --global alias.noff "merge --no-ff" git config --global alias.ffonly "merge --ff-only"之后想强制合并就敲git noff feature，想测干净合入就敲git ffonly feature。
如果你还想在团队里做强制检查，可以在 CI 里加一个很简单的脚本。比如检查最近 N 个提交中主干是否存在非 merge 提交：
#!/usr/bin/env bash set -euo pipefail N="${1:-20}" main="${2:-origin/main}" echo "检查最近 ${N} 个提交..." if git log --first-parent --no-merges --oneline -"${N}" "${main}" | grep -q .; then echo "发现非 merge 提交，请确认功能分支是否漏了 --no-ff：" git log --first-parent --no-merges --oneline -"${N}" "${main}" exit 1 fi echo "主干历史符合合并规范"这个脚本只是一个雏形。如果你们团队约定的是"主干只允许 squash 提交"，那检查逻辑就改成统计 squash merge 标记；如果你们完全走 rebase 流，那就反过来检查有没有意外的 merge 节点。关键是把规范变成机器可检查的规则，而不是靠群里喊口号。
我自己现在的习惯其实非常简单：本地仓库或者临时分支，能用 FF 就 FF，省得历史里到处都是无意义的空 merge 节点；凡是涉及共享主干、发布记录、回滚预案的功能合入，一律--no-ff，让每个功能都以一个清晰的 merge 节点收尾。
这个习惯看着只是多敲了一个参数，但在做代码回溯、发布排查、功能回滚的时候，是真的能省下大半天时间的。如果你刚接触 Git 没多久，不需要一次性记住所有细节，先把"合并先看--graph、回滚先想有没有 merge 节点"这两个意识建立起来，后面这些概念慢慢都会串到一起。
