必需评审与代码所有者
受保护分支可以要求合并前至少获得若干名批准，并可以额外要求代码所有者批准。两者叠加时必须同时满足：既达到批准人数，也要覆盖改动路径的代码所有者点头，缺一项都无法合入。
基本信息
| 设置位置 | 仓库设置中的分支保护规则 |
|---|---|
| 常见开关 | 合并前必须提交评审请求、必需批准数、要求代码所有者批准 |
| 组合效果 | 既满足批准人数，又覆盖受影响路径的所有者 |
| 所有者来源 | 仓库里声明归属关系的文件，按路径模式匹配 |
| 例外配置 | 可允许管理员绕过，或允许特定角色自行合并 |
典型使用场景
- 关键仓库要求至少两人把关改动
- 按目录自动找到真正懂这块代码的评审人
- 合规场景要求变更具备明确的批准记录
- 大团队里避免出现「谁有空谁审」的随机分工
- 外包与内部协作需要区分批准权限
常用示例
常用示例
gh api repos/{owner}/{repo}/branches/main/protection | head -40 # 查看保护规则
gh pr view 128 --json reviewDecision # 查看评审决定状态
gh pr view 128 --json reviews # 查看已提交的评审记录
gh pr checks 128 # 确认检查项状态配置组合与效果
| 配置 | 效果 |
|---|---|
| 仅必需批准数 | 任意有权限的人批准即可 |
| 仅代码所有者评审 | 覆盖路径的所有者必须批准 |
| 两者同时开启 | 人数与所有者条件都要满足 |
| 允许管理员绕过 | 紧急通道，审计时要重点关注 |
小团队启用代码所有者评审前，先确认每个目录都有可用负责人，否则会出现无人可批、评审请求长期卡住的瓶颈。
批准人数并非越多越好：人数过多会拉长等待时间，成员倾向于私下凑够批准，反而降低评审质量。
同一人多次提交批准不会重复计数，需要看到新的改动后重新批准才会生效，这一点在推送给改动之后尤其要注意。