企业中Fast-forward不可接受，因其抹去分支边界导致审计链断裂；须通过Git Hook拦截、PR准入检查、主干保护策略三大硬手段刚性落地--no-ff，并配套语义化分支命名与标准化合并信息。
Git 的 Fast-forward（快进）机制本身不是问题，但默认启用它会在合并时抹去分支边界信息——这对需要可追溯、强审计的企业环境是重大风险。要刚性推行 --no-ff，关键不在命令本身，而在机制设计与流程卡点。
Fast-forward 为什么在企业中不可接受
Fast-forward 合并只是移动分支指针，不生成新提交。结果是：
- 历史日志里看不出某次提交来自哪个功能分支，也无法区分是直接提交还是合并引入
- 删除 feature 分支后，该分支的全部开发上下文（起止时间、负责人、关联需求）彻底丢失
- 审计时无法回答“v2.3 版本中登录模块的改动，是由哪次 PR 引入？由谁在哪天合入？”这类问题
- CI/CD 流水线若依赖分支名打标签或触发构建，快进后分支名信息在历史中不可查证
刚性落地 --no-ff 的三个硬性手段
不能靠开发者自觉执行 git merge --no-ff，必须嵌入流程：
- Git Hook 强制拦截：在 CI 侧部署 pre-receive hook，拒绝所有不含 merge commit 的 push（即检测提交的 parent 数是否为 1 且非初始提交）。对非合并提交直接拦截并提示“请使用 --no-ff 合并”
-
PR 模板与准入检查：GitHub/GitLab 的 Pull Request 模板中明确要求填写“源分支名”“关联需求号”“测试验证结论”，并在合并前自动运行脚本检查目标提交是否为 merge commit（
git cat-file -p <commit> | grep "^parent" | wc -l≥ 2） -
主干保护分支策略：将
main和release/*设为受保护分支，仅允许通过 PR 合并，且禁用 “Allow merge commits” 以外的合并选项（即关闭 Squash、Rebase 选项），只保留 “Create a merge commit” 并预设勾选 “Include all commits from the head branch”
配套分支命名与归档规范
--no-ff 生效的前提是分支本身有语义。需同步推行：
- 所有功能分支强制前缀：
feat/xxx、fix/xxx、refactor/xxx，禁止使用dev、test等模糊名称 - 每次 --no-ff 合并必须带清晰 message，格式统一为：
merge feat/user-auth into main #REQ-1234（含需求编号） - 合并成功后，自动触发 GitHub Action 删除源分支，并在 issue 中自动评论“✅ 已合入 main，分支已清理”
真正让 --no-ff 成为铁律，靠的不是教人怎么敲命令，而是让“不这么做”根本走不通。审计链完整不是靠事后翻 log，而是从第一次提交开始，就让每个节点自带上下文。
