分支保护解决什么
分支保护把评审要求固化成规则：主干必须通过流水线检查、达到约定的批准人数、解决所有讨论后才能合并，并禁止直接推送。它解决的是「人都忙起来时规则被顺手跳过」的问题。规则只提供兜底，不提供判断——合入质量仍取决于评审者实际投入的注意力。
基本信息
| 必需检查 | 流水线必须通过：构建、测试、静态检查 |
|---|---|
| 必需批准 | 按仓库风险设置人数（常见 1 到 2 人） |
| 讨论处理 | 要求所有讨论已解决，避免口头已解决的无记录处置 |
| 推送限制 | 保护分支只能通过合并请求进入 |
最小可用规则集
- 必需状态检查：构建与测试必须绿，且检查项本身要稳定。
- 至少一人批准：作者不能批准自己的改动。
- 要求解决所有讨论：处置过程留痕在 PR 里。
- 禁止直接推送：所有改动经过合并请求与流水线。
- 管理员绕过留记录：例外要能在回顾时被复盘。
- 规则同样覆盖发布分支与长期维护分支，避免主干之外成为绕过通道。
- 检查项只保留稳定的那些，不稳定检查会训练团队习惯性绕过。
- 受保护分支的名单随仓库结构更新：临时分支变成长期分支后要及时补上规则。
配置与副作用
| 配置 | 副作用 |
|---|---|
| 检查项不稳定却设为必需 | 团队常态化用管理员权限绕过 |
| 批准数设得太高 | 小改动也排队，团队想办法绕流程 |
| 允许作者自批准 | 评审约束名存实亡 |
| 不限制直接推送 | 紧急时刻的改动完全没有记录 |
规则是兜底而不是替代：合入质量仍以人工评审为准，规则只能保证「有人看过」。
管理员绕过权限要谨慎使用：每次绕过都应留下原因，并在团队回顾中检查频率，异常升高说明流程本身需要调整。