敏捷团队必须把main分支设为保护分支，因为迭代快、变更集中，直接推送未测试代码会立即破坏CI或引发线上故障；保护规则启用enforce_admins:true后，管理员也不能豁免，可防止“临时通融酿大祸”。
为什么敏捷团队必须把 main 分支设为保护分支
因为敏捷迭代快、合并不频繁但变更集中，main 分支一旦被直接推送未测试代码，就可能立刻破坏 CI 流水线或导致线上故障。保护分支不是“防新人”，而是防“赶着上线时绕过流程”的惯性操作。
- 每次 Sprint 结束前的批量合并，容易因疏忽跳过 PR 审查或状态检查
- 开发者本地
git push origin main失败，其实是系统在帮你拦截风险，不是权限问题 - 保护规则启用
enforce_admins: true后，连仓库管理员也不能豁免——这点常被忽略，但恰恰是防止“临时通融酿大祸”的关键
分支保护如何堵住 CI/CD 流水线里的漏洞
光有 GitHub Actions 或 GitLab CI 配置还不够，没配分支保护，CI 就只是个可选开关。只有当 required_status_checks 绑定到受保护分支，才能真正让“测试不通过=不能合并”成为硬约束。
- 常见错误：CI 脚本里写了
npm test，但没在分支保护里勾选对应 status context（比如ci/test），结果 PR 仍可绕过测试合并 - 多个检查项（如单元测试、安全扫描、构建）必须全部出现在
contexts列表中，缺一不可 - 如果用了自定义 workflow 文件名（如
.github/workflows/ci-deploy.yml），status context 默认是ci-deploy，不是文件名全路径，别填错
“Require pull request reviews” 不等于“有人点 Approve 就行”
很多团队开了这个选项却依然出问题，是因为没关掉两个危险默认值：作者自批、过期审查不作废。
- 务必勾选
Dismiss stale reviews when new commits are pushed，否则老 review 会一直挂着，新改的 bug 就漏过了 - 启用
Require code owner reviews后，修改src/payment/目录的 PR 会自动 @ 对应的CODEOWNERS成员，比靠人盯更可靠 - 禁止作者批准自己的 PR —— 这个选项叫
Include administrators的反向逻辑容易混淆：它控制的是“管理员是否受规则限制”，不是“谁可以批准”。真正禁自批要单独开Require approvals并配合Restrict who can approve
GitLab / GitHub / GitCode 的保护规则差异点
表面功能相似，但权限继承逻辑和 UI 路径不同，跨平台迁移时最容易栽跟头。
- GitHub 的
restrictions是按 team/user 显式白名单；GitLab 的Allowed to merge是角色粒度（Maintainer / Developer），且默认 Developer 不能 merge 到 protected branch - GitCode 报错
error:无法推送至保护分支'main':权限被拒绝，90% 情况下不是账号没权限，而是当前分支规则要求CI passed + 1 review，而你只做了 push，没走 PR 流程 - 所有平台都支持 glob pattern（如
release/*），但 GitLab 对**支持更宽松，GitHub 要写成release/**才生效
CODEOWNERS 和分支保护联动起来。没人愿意手动找 reviewer，但文件级自动路由能真正让“谁改谁负责”变成可执行规则。 
