分支保护是防止协作失序的最小必要防线，需强制PR审查（至少2人批准并自动作废旧审）、绑定CODEOWNERS、禁用自合并与强制推送，并严格配置CI多维度检查及精确分支匹配规则。
分支保护不是“加个开关就完事”的配置项，而是大型敏捷团队里防止协作失序的最小必要防线。 它直接决定 PR 流程是否被绕过、CI 是否形同虚设、谁能在什么条件下改掉生产代码——这些不是权限问题，是流程崩塌的起点。
为什么 main 分支必须启用 require_pull_request_reviews
在 10+ 人并行开发的敏捷团队中，没有审查强制的分支等于开放编辑的共享文档。常见错误现象包括：开发者本地测试通过后直接 git push origin main，跳过 CI 和人工检查；或 PR 被作者自己 approve 后合并（GitHub 默认允许，需显式禁用）。
实操建议：
• 必须设置 required_approving_review_count: 2，且启用 dismiss_stale_reviews_on_push: true（新提交自动作废旧审查）
• 开启 require_code_owner_reviews: true，配合 .github/CODEOWNERS 文件绑定关键模块责任人
• 禁用 allow_self_merge 和 allow_auto_merge，避免自动化绕过人工判断
CI 状态检查为何不能只配 ci/build 一个 context
单一构建成功不等于代码安全。大型项目常因漏配导致漏洞上线：例如依赖扫描（security-scan）、性能回归（performance-test）、合规检查（license-audit）全部被跳过。
实操建议：
• 每个环境分支对应不同检查集： main 分支至少含 unit-tests、security-scan、build 三项
• 使用 enforce_admins: true 防止管理员误操作绕过
• 若使用 GitHub Actions，确保 workflow 文件中 if: github.event_name == 'pull_request' && github.base_ref == 'main' 条件准确，避免仅对 push 触发而漏检 PR
GitLab 中 protected branches 的权限陷阱
GitLab 默认允许 Maintainer 强制推送（git push -f），这在回滚场景下看似方便，实则极易破坏历史线性——尤其当多人基于旧 HEAD 继续开发时，会触发不可逆的分叉。
实操建议：
• 在保护规则中明确关闭 Allow force push（即使对 Maintainer）
• 回滚必须走 revert 提交而非 reset + force push，保留原始 commit hash 可追溯
• 对 main 和 production 分支，将 Allowed to merge 和 Allowed to push 权限拆开：仅 Release Engineer 拥有 merge 权限，运维拥有 push 权限（极少使用）
分支命名策略如何影响保护规则有效性
通配符规则（如 release/*）若未配合严格命名规范，会导致保护失效：例如 release/v1.2.0-hotfix 匹配成功，但 release-hotfix 不匹配，后者变成裸奔分支。
实操建议：
• 保护规则优先用精确匹配（main、develop），通配符仅用于明确模式（feature/**、hotfix/**）
• 在 CI 中增加分支名校验 step，拒绝不符合 ^release/v[0-9]+\.[0-9]+\.[0-9]+$ 的推送
• 避免使用 * 单字符通配（GitLab 支持，GitHub 不支持），统一用 ** 表示多级路径
真正难的不是配置开关，而是让每条规则在每天数百次 PR 中持续生效——这取决于你是否把分支保护当成流程的一部分，而不是部署前补上的装饰。
