必需评审是什么
分支保护要求合并前获得指定数量的评审批准，并可在新提交后自动作废旧批准；目标是让变更在合入前经过独立于作者的第二双眼睛。批准数量按风险设置，代码所有者文件可要求特定路径必须由对应团队批准，未解决的评审对话可以阻止合并，形成完整的合并门禁。评审通过与自动检查共同构成合并门禁，缺一不可。
基本信息
| 批准数量 | 按风险设置，如 1 到 2 人 |
|---|---|
| 失效策略 | 新提交自动驳回旧批准 |
| 代码所有者 | 特定路径须由对应团队批准 |
| 对话解决 | 未解决的评审对话可阻止合并 |
| 适用范围 | 保护分支上的合并请求 |
| 例外管理 | 高危变更走记录在案的例外流程，事后补审 |
保护项与效果
| 保护项 | 作用 | 防住的问题 |
|---|---|---|
| 批准数 | 合并前需指定人数批准 | 单人直线合入 |
| 失效批准 | 新提交后旧批准作废 | 审旧代码、合新代码 |
| 代码所有者 | 路径级强制评审 | 核心模块被绕过 |
| 对话解决 | 未决讨论阻断合并 | 问题被无声忽略 |
查看分支保护要求
查看分支保护要求
# 查看分支保护的评审要求
gh api repos/OWNER/REPO/branches/main/protection \
--jq '.required_pull_request_reviews.required_approving_review_count'
# 查看是否要求代码所有者评审
gh api repos/OWNER/REPO/branches/main/protection \
--jq '.required_pull_request_reviews.require_code_owner_reviews'典型使用场景
- 主干分支保护：所有变更经独立评审后合入，防止直线提交
- 核心模块治理：用代码所有者规则强制架构或安全团队评审
- 变更后复审：新提交使旧批准失效，保证审的就是最终版本
- 紧急通道管理：保留受控的紧急合并通道，事后补齐评审并记录原因
- 团队协作规范：把批准数量与对话解决要求一并绑定到分支保护
- 新人引导：关键变更经评审获得上下文输入，减少隐性知识断层
紧急变更保留受控通道：事后补齐评审并记录原因。
允许自批准会削弱门禁意义：作者点自己批准等于没有独立评审。