必须确认develop已完成全部功能集成且通过冒烟测试，才能向release分支合并；否则将导致UAT环境直面上线风险。
必须确认 develop 已完成本次发布全部功能集成，且通过冒烟测试，才能向 release 分支合并。 其他任何“看起来差不多”“先合过去再修”的操作，都会让 release 失去预发布意义，把上线风险直接带进 UAT 环境。
develop 分支是否已集齐本次发布所有功能？
这是最常被跳过的硬性门槛。release 分支不是“临时收口区”，它只接受一个完整、自洽的发布快照。
- 检查
git log develop..origin/develop，确认本地develop与远程一致，没有遗漏他人刚合入的 PR - 核对本次发布的功能清单（PR 或需求 ID 列表），逐条确认对应
feature/*分支均已合并进develop，且无revert提交回退 - 禁止用
git merge feature-x直接往 release 上加功能——这会绕过 develop 的集成验证，导致版本不一致
冒烟测试是否已在 develop 上通过？
冒烟测试不是可选项，而是 release 创建前的闸门。它验证的是“集成后主干是否能跑通”，不是功能细节。
- 必须在
develop分支上执行完整冒烟用例（登录、首页加载、核心流程跳转等），不能仅在本地或某 feature 分支上跑 - CI 流水线中需有明确的
smoke-test-on-develop阶段，且状态为passed才允许后续动作 - 若冒烟失败，修复必须回到
feature/*或bugfix/*分支，重新走合并流程，而不是在develop上直接 commit
是否有未解决的阻断性问题仍留在 develop？
阻断性问题（如编译失败、关键接口 500、数据库迁移脚本缺失）必须清零，否则 release 分支一建就处于不可测状态。
- 检查 CI 构建日志，确认
build、test、lint全部通过，无ERROR或FATAL级别报错 - 查看 issue 跟踪系统，过滤标签为
blocker或critical且状态非closed的项，确认其不属本次发布范围，或已明确延期 - 禁止将 “这个 bug 下个版本修” 作为准入理由——release 只承载“已确认可交付”的代码
真正卡住 release 合并的，往往不是技术操作，而是对“本次发布边界”的模糊判断。一旦 develop 上存在未验收的功能、未关闭的阻断项、或未经冒烟验证的集成结果，强行创建 release 就等于把测试成本转嫁给 UAT 和生产环境。
