GitLab MR 审批机制
GitLab 用合并请求（MR）承载评审，审批行为由 Approval Rules 与 Code Owners 共同约束：可以要求指定人数或指定团队批准，某些路径的改动必须由对应 owner 批准；任一评审者请求修改都会阻止合并，直到问题被解决。这些规则的作用是兜底，确保任何改动至少经过团队约定的眼睛数量。
基本信息
| 审批规则 | 按目标分支配置所需批准人数（如 1 至 2 人） |
|---|---|
| 代码所有者 | 指定路径的改动必须由对应 owner 批准 |
| 阻塞机制 | 任一评审者请求修改即阻止合并，直到解决 |
| 重置策略 | 可配置推送新提交后是否重置已有批准 |
常用配置要点
- 按目标分支设置批准数：主干严格、特性分支宽松，避免一刀切。
- Code Owners 规则覆盖高风险目录（支付、权限、数据迁移）。
- 开启「推送新提交后重置批准」：防止未经评审的新代码沿用旧批准。
- 要求解决所有讨论才能合并：避免口头已解决但无记录的处置。
- 删除或修改审批规则本身也要走评审：规则放宽等于降低整个仓库的门槛。
规则强度与代价
| 配置 | 好处 | 代价 |
|---|---|---|
| 要求多人批准 | 关键改动有更多视角 | 小改动也要排队，团队可能绕流程 |
| 必须 owner 批准 | 领域专家把关 | owner 忙时成为瓶颈 |
| 重置旧批准 | 批准始终对应当前代码 | 评审者需要重复确认增量 |
| 要求解决讨论 | 处置有记录 | 作者忘记回复时改动会被卡住 |
规则的价值在于兜底：确保任何改动至少有团队约定数量的眼睛，而不是替代人工判断。
开启「重置批准」后若评审者不看增量就点批准，规则会退化为形式，改动实际仍未被复核。
紧急修复可以走例外通道，但要在事后补评审：绕过硬性规则的动作需要留痕，否则例外会变成常态。