审批规则是什么
GitLab 的审批规则用来规定一个合并请求在合并前需要几人批准、由谁批准。它在项目设置里维护，可以叠加多条规则，并分别指定适用的目标分支、新增提交后是否重置已有审批、是否把代码所有者纳入必审范围。审批规则是准入条件，不能代替人对改动的判断。
基本信息
| 配置路径 | 项目 → Settings → Merge requests → Approval rules |
|---|---|
| 常见字段 | 审批人数、适用目标分支、新提交是否重置审批、是否允许作者批准 |
| 规则叠加 | 多条规则需同时满足才算通过 |
| 配合机制 | 可与 CODEOWNERS 组合，要求代码所有者审批 |
| 生效范围 | 该项目（或指定受保护分支）内的合并请求 |
典型使用场景
- 主干分支要求两人批准、普通分支一人批准，按风险分级设置
- 涉及基础设施、支付等敏感目录的合并请求强制指定团队审批
- 依赖升级类改动要求安全团队会签
- 开启新提交重置审批，确保批准针对的是最终版本
- 在高频小改动分支上放宽人数，避免流程成为交付瓶颈
典型规则组合
典型规则组合
规则一：任意目标分支，需 1 名审批人
规则二：目标为 main，需 2 名审批人
规则三：变更包含 infra/ 路径，需 SRE 组成员审批
规则四：新增提交后重置已有审批规则字段读法
| 字段 | 含义 | 常见取值 |
|---|---|---|
| 审批人数 | 满足该规则所需的批准数量 | 1 / 2 / 自定义人数 |
| 适用分支 | 规则匹配的目标分支 | 具体分支名或通配写法 |
| 重置审批 | 新推送是否作废已有批准 | 开启 / 关闭 |
| 代码所有者 | 是否要求代码所有者审批 | 开启 / 关闭 |
规则越多流程越重，按风险分层更实用：高风险目录加严，日常改动保持一名审批人。审批人尽量配置成组而不是个人，避免成员转岗后合并请求无人可批。
如果关闭「新增提交重置审批」，批准可能只覆盖旧版本。想保证批准针对最终版本，建议开启重置，并同时禁止作者自我批准。