fast-forward合并触发条件是：目标分支（如main）必须是源分支（如feature）的直接祖先，即main自分离后无新提交，且feature历史为线性延续；此时git自动将main指针前移至feature最新提交，不产生新commit。
什么时候触发 Fast-Forward 合并
Git 执行 git merge 时，只要目标分支（比如 main）的最新提交是源分支（比如 feature）的**直接祖先**，就会自动走 Fast-Forward 模式。这不是可选项，而是 Git 的默认行为。
常见触发场景包括：
- 你在
feature上开发完，main自从你切出feature后就再没收到任何新提交 -
feature是从main的某个 commit 线性提交而来，中间没有分叉 - 执行
git merge feature前，main和feature的提交历史呈「一条直线」
此时 Git 不会创建新提交，只是把 main 的指针直接挪到 feature 的最新 commit 上。历史仍是线性的，但你也因此丢失了「这次合并发生过」的元信息。
非快进合并（--no-ff）为什么必须加 -m 参数
当你用 git merge --no-ff feature 强制生成合并提交，Git 会创建一个有两个父提交的新 commit——它同时指向 main 当前 HEAD 和 feature 的最新 commit。这个 commit 必须有明确的提交信息，否则操作失败。
原因很简单：Git 不允许空消息的合并提交。如果不加 -m，你会看到错误：
Commit message required for non-fast-forward merge.
正确写法是：
git merge --no-ff -m "merge feature/login-ui into main" feature
注意：--no-ff 不等于解决冲突——即使没冲突，只要加了这个 flag，就一定产生新 commit；而冲突本身会强制进入非快进流程，无需额外加参数。
fast-forward 合并后删掉 feature 分支，历史还能追溯吗
不能。这是 fast-forward 最常被低估的副作用。
因为没产生合并提交，所有 feature 上的 commit 都直接“融入”了 main 的线性历史。一旦你执行 git branch -d feature，那个分支名就彻底消失，且没有任何记录表明这些提交曾属于一个独立功能分支。
想保留可追溯性，就得主动禁用 fast-forward：
- 日常团队协作中，建议对所有合入
main或release的分支统一用--no-ff - 用
git log --graph --oneline --all可直观看出哪些是合并点（带\ /分叉结构） - CI/CD 流水线里如果依赖分支来源做权限或构建策略，fast-forward 会让这类逻辑失效
如何判断一次 merge 到底走了哪种模式
最直接的方式是看 git log 输出里有没有「合并提交」：
- 如果最新 commit 的
git show显示Merge: abc123 def456，说明是非快进 - 如果最新 commit 只有一个 parent（
parent abc123），且和被合并分支 tip 完全一致，那就是 fast-forward
也可以在 merge 前预判：
git merge-base --is-ancestor main feature && echo "可快进" || echo "必非快进"
这条命令检查 main 是否是 feature 的祖先——返回真，就代表 fast-forward 成立；否则 Git 一定会走三向合并流程。
真正容易忽略的不是技术细节，而是团队规范：是否所有人对 --no-ff 达成共识、是否 CI 脚本能兼容两种合并产生的不同图谱结构、以及当某人忘了加 --no-ff 时，有没有机制及时发现并补救。
