--no-ff强制Git创建合并提交，解决快进合并导致分支边界消失、历史无法追溯功能来源的问题。它确保每次合并都生成含两个父节点的明确提交，清晰标识集成动作，适配Gerrit审查与CI/CD流程。
什么是 --no-ff，它解决什么问题
默认情况下，Git 在执行 git merge 时，如果当前分支是目标分支的直接后代（即快进可达成），就会跳过创建合并提交，直接移动指针。这会让特性分支的边界消失，历史变成一条直线，无法区分哪些提交属于哪个功能或修复。
--no-ff 强制 Git 总是生成一个合并提交（merge commit），哪怕可以快进。这样，每次 git merge feature/login 都会留下一个明确的、带两个父提交的节点，清晰标出一次集成动作。
如何正确使用 git merge --no-ff
最直接的方式是在合并时显式加参数：
git checkout main<br>git merge --no-ff feature/login
这个操作会打开编辑器让你填写合并信息，默认是 Merge branch 'feature/login'，建议保留或稍作补充（如加 Jira ID）。
常见误操作：
- 在
feature/login分支上运行git merge --no-ff main—— 这是反向合并，容易污染特性分支历史 - 忘记先
git checkout到目标分支（如main或develop）再合并 - 用
--no-commit混淆了--no-ff：前者阻止自动提交，后者强制生成合并提交
让 --no-ff 成为默认行为
如果你团队约定所有合并都必须保留分支结构，可以全局或仓库级配置：
git config --global merge.ff false
这个设置会让所有 git merge 默认等价于 git merge --no-ff。注意：false 表示禁用快进，true（默认）才允许快进。
配置后仍可临时覆盖：
git merge --ff feature/quick-fix # 强制快进（不推荐用于特性分支）
但要注意：CI/CD 流水线中若依赖 git log --first-parent 提取主线历史，--no-ff 是前提；否则 --first-parent 会跳过所有合并提交的第二父（即特性分支），导致漏掉关键变更。
和 rebase 的关键区别在哪
有人误以为 rebase 也能“保留历史”，其实恰恰相反：git rebase main 会把特性分支上的提交线性重放，抹掉原始分支上下文，丢失“这个功能是一组协作完成的”这一事实。
--no-ff 合并保留的是协作边界与时间线，而 rebase 追求的是线性整洁——二者目标不同，不可互相替代。
典型陷阱：
- 对已推送的特性分支做
rebase，然后push --force，导致队友本地历史失效 - 用
rebase替代--no-ff来“避免合并提交”，结果让 Code Review 记录、CI 构建关联全部断裂
真正需要的不是“没有合并提交”，而是“合并提交有意义”。所以重点不在删掉它，而在让它承载准确的上下文——比如确保 feature/* 分支命名规范、合并前有测试通过、合并信息写清目的。
