--no-ff是ci可追溯性的底线保障，它强制生成含两个父节点的合并提交，固化pr元信息，确保git log中清晰标识集成动作，适配gerrit审查与ci/cd流程。
持续集成中默认的 git merge 行为（即 --ff）在多数自动化场景下反而容易埋雷——它不创建合并提交，导致 CI 流水线无法准确关联 PR 与最终上线版本。
为什么 --ff-only 在 CI 中常被误用
很多人以为 --ff-only 是“更安全”的合并方式，其实它只做一件事：拒绝任何分叉历史。一旦远程分支和本地 HEAD 不在同一条直线上（比如 CI 机器拉取了旧 master、而别人刚 push 了新提交），git pull --ff-only 就会直接失败，中断流水线。
- 常见错误现象：
fatal: Not possible to fast-forward merge，但日志里没说明是哪条分支落后 - 真实使用场景：适合部署前的 final check，比如 tag 构建或发布分支锁定，而非日常 PR 合并
- CI 配置建议：除非你严格控制所有推送节奏（例如仅允许 bot 推送 + pre-merge hook 校验），否则别在
git merge或git pull步骤中无条件启用--ff-only
--no-ff 是 CI 可追溯性的底线保障
只要你想在 git log 里一眼看出“这个 release 包含哪些 PR”，就必须用 --no-ff。它强制生成合并提交，把 PR 的 SHA、标题、作者等元信息固化进历史。
- 性能影响几乎为零：只是多一个 commit 对象，不影响 clone 速度或 diff 效率
- 兼容性注意点：GitHub/GitLab 的 “Merge commit” 模式默认就是
--no-ff，但如果你用自建 CI 调用git merge，必须显式加参数，否则退化成--ff - 容易踩的坑：某些 CI 脚本用
git merge origin/main而没写--no-ff，结果 PR 记录消失，回溯时只能靠 GitLab UI 查，没法用git blame或git log --merges
--ff 何时能放心用
--ff 不是错的，而是有明确边界：它只适用于“单向推进、无并发写入”的分支模型，比如构建临时工作区或基于 tag 的离线打包。
- 典型安全用法：
git checkout -b build-$(date +%s) && git merge --ff origin/release/v2.3，这里 origin/release/v2.3 是只读冻结分支 - 危险用法：
git merge --ff origin/main在 CI job 中执行——因为origin/main可能已被其他 job 更新，导致实际行为变成 fast-forward 或 silent fail（取决于 Git 版本） - 参数差异关键点：
--ff是默认值，但 CI 脚本里最好显式写出，避免被未来 Git 版本策略变更影响（例如带签名 tag 时默认改用--no-ff）
真正难的是让团队对“什么算一次有意义的合并”达成共识——--no-ff 解决了可追溯性，但不会自动解决冲突粒度、提交语义或 PR 描述质量。这些才是 CI 历史是否真正可用的底层决定因素。
