新提交重置审批是什么
GitLab 可配置「推送新提交时移除已有批准」（Reset approvals on push），确保批准只对应被评审过的版本；关闭它则需要额外的「最后推送人不可批准」类约束来兜底。这是把「评审结果与被评代码绑定」的机制。
基本信息
| 位置 | 项目 Settings → Merge requests → Approvals |
|---|---|
| 开启效果 | 每次推送新提交，已有批准全部重置 |
| 关闭时建议 | 配合作者与最后推送人不可自批的约束 |
| 权衡 | 严格设置降低流转速度，宽松设置依赖自律 |
| 相关设置 | 最少批准数、批准人范围（按角色/组） |
| 观测 | 合并时长与重置次数可作流程健康度指标 |
典型使用场景
- 高风险仓库：要求批准必须对应最新版本，开启重置。
- 评审加速：被重置后评审人只需复核增量改动，比全量重评快。
- 变更说明：推送后告知评审人「本轮只改 X」，减少重复沟通。
- 合规基线：审批链与代码版本对应，审计时可回放。
- 流程调优：统计重置频率，定位反复推送的根因。
- 例外管理：紧急场景走管理员通道，事后补记录。
- 新成员引导：把「重置意味着什么」写进评审指南，减少困惑。
检查配置路径
检查配置路径
Project → Settings → Merge requests
Approvals
- Reset approvals on push（推荐开启）
- Prevent approval by author（按需）
- Prevent approvals by users who add commits（按需）设置组合与效果
| 设置 | 效果 | 注意事项 |
|---|---|---|
| 重置批准：开 | 新提交后批准作废 | 严格，适合高风险仓库 |
| 重置批准：关 | 批准长期有效 | 依赖自律，需自批约束兜底 |
| 禁止作者批准 | 作者不能自己批 | 配合最少批准数使用 |
| 最少批准数 | 低于数量不能合并 | 按风险定 1 到 2 人 |
被重置后评审人只需复核增量改动，通常比重新全量评审快；在 MR 里说明「本轮只改 X」能加速流转；重置频繁时先查原因（CI 不稳、推送习惯），再谈流程调整。；设置调整后观察一周的流转数据再定稿。