撤销过时审批是什么
开启「新提交推送后撤销过时审批」之后，任何新增提交都会清空已有的批准记录，确保批准对应的是评审人真正看过的那个版本。它解决的是「批准之后又被追加未经评审的改动」这类问题，代价是每次补提交都需要重新确认一次。
基本信息
| GitHub 位置 | 分支保护设置中的撤销过时审批选项 |
|---|---|
| GitLab 对应 | 审批规则中配置新提交时移除已有审批 |
| 目的 | 防止批准之后被追加未经评审的改动 |
| 效果 | 已有批准被标记为过时，需要重新请求评审 |
典型使用场景
- 主干等受保护分支上强制批准与代码版本一一对应
- 合规或审计要求批准有明确对应的提交
- 修复小问题后重新请评审人确认
- 排查「明明批准了为什么还不能合并」
- 在评审节奏快、补提交频繁的仓库里用它兜底
观察行为
观察行为
git push origin feature/login # 推送新提交后原有批准会被标记为过时
git log --oneline -3 # 确认本轮推送了哪些提交
gh pr view 128 --json reviewDecision,mergeStateStatus # 查看当前评审与可合并状态行为对照
| 动作 | 结果 | 后续 |
|---|---|---|
| 追加新提交 | 已有批准被标记过时 | 需要重新请求评审 |
| 只改描述或标签 | 批准通常保留 | 不影响合并 |
| 强推改写历史 | 按平台实际状态判断 | 以平台当前显示为准 |
若团队习惯用追加小改动的方式迭代，先与评审人约定：改动很小可以重新确认一次，改动较大就重新走一轮完整评审。
撤销机制变严格之后合入节奏会变慢，这是刻意的权衡；需要豁免的场景应显式写进团队规范，而不是靠临时沟通。
配合做法
- 在团队规范里写清哪些改动需要重新评审
- 用更小的提交减少重新评审带来的往返
- 评审人对增量改动给出明确结论，而不是默认继续有效
- 发现合并受阻时先检查批准是否已经过时