GitHub Rulesets 怎么只限制发布分支

GitHub Rulesets 只限制发布分支，关键不是先勾保护项，而是先把 Target branches 的目标范围收窄：单层发布分支用 release/*，可能包含多级目录的发布分支用 release/**/*。不要选择 All branches，也不要把 Default branch 当作发布分支范围。这样规则集会保护 release/1.8 一类分支，同时不影响 main、develop 和 feature/login。

官方文档：https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository

先确定发布分支到底有几层

GitHub 的分支规则模式使用 fnmatch 语法。由于路径匹配按目录分隔符处理，* 不会跨过斜杠。因此，release/* 适合 release/1.8、release/2026-10 这样的单层命名，但不会覆盖 release/hotfix/1.8.1。如果团队允许发布分支继续分层，就应改用 release/**/*。

若仓库目前只有单层发布分支，优先使用范围更小的 release/*。只有命名规范确实允许多层目录时，再扩大到 release/**/*，避免未来出现意外命中。

步骤一：新建分支规则集，先保持 Disabled

1. 进入目标仓库，依次打开 Settings > Rules > Rulesets。
2. 点击 New ruleset > New branch ruleset。
3. 在 Ruleset Name 填写 release-branch-policy。
4. 配置阶段先把 Enforcement status 保持为 Disabled，完成范围核对后再激活。

这一步的成功状态是：页面顶部显示 release-branch-policy，类型为分支规则集，Enforcement status 仍是 Disabled。Disabled 适合先配置、先核对，不会立即把未完成的规则施加到开发流程。

步骤二：只添加发布分支模式

1. 找到 Target branches 区域，点击 Add a target。
2. 选择 Include by pattern，不要选 All branches。
3. 单层发布分支输入 release/*；需要覆盖多级目录时输入 release/**/*。
4. 点击 Add inclusion pattern 保存目标模式。

保存后，Target branches 区域应只显示刚添加的包含模式。若同时存在 Default branch、All branches 或过宽的包含模式，先删除多余目标；否则即使保护规则本身正确，也会把范围扩到非发布分支。

步骤三：选择保护项并切换为 Active

在 Rules 区域按团队发布流程启用规则。对多数发布分支，下面四项已经能形成清晰的最小保护集合：

• Require a pull request before merging：发布改动必须经过 Pull Request，而不是直接推送。
• Require status checks to pass before merging：至少添加一个实际存在的 CI 检查；若还要求分支保持最新，也要先选定具体检查。
• Block force pushes：阻止重写发布分支历史。
• Restrict deletions：避免发布分支被随意删除。

不要把 Restrict updates 当作“必须走 PR”的同义项。它会把更新权限收紧到旁路名单中的角色、团队或应用，配置不当时，正常 Pull Request 合并也可能被拦截。只有明确要求“仅发布管理员或部署应用可更新”时才启用，并提前配置对应 Bypass list。

旁路名单应遵循最小权限：只加入发布负责人、发布团队或部署应用。如果希望这些角色仍然留下 Pull Request 记录，可以把旁路方式限制为 For pull requests only。不要为了省事给全部管理员添加宽泛旁路，否则规则表面 Active，关键人员却可以完全绕过。

确认 Target branches、规则和 Bypass list 后，把 Enforcement status 改为 Active，再点击页面底部的 Create。Active 规则集创建后会立即对命中的分支生效。

结果核对：先看命中范围，再看操作限制

回到 Settings > Rules > Rulesets，打开 release-branch-policy。先确认状态为 Active，目标模式没有混入 All branches，再按下表验证。这里的“验证”是检查规则设计是否符合仓库命名，不需要为了测试而修改生产发布分支。

常见异常与修正

多级发布分支没有被保护

原因通常是使用了 release/*。它只覆盖一个斜杠后的单层名称。把目标模式改为 release/**/*，再重新核对单层和多层分支。

main 或 feature 分支也被限制了

先检查本规则集是否误选 All branches、Default branch 或其他过宽模式。如果这里没有问题，再查看仓库中的其他 Rulesets 和 Branch protection rules。GitHub 会聚合同一分支上的多套规则，重叠时以更严格的结果为准，因此影响来源不一定是当前规则集。

勾选状态检查后仍能直接合并

仅打开 Require status checks 还不够，需要在该规则下添加实际的 CI 检查。若没有可选项，先让对应工作流在仓库中成功运行一次，再回到规则集选择检查名称。

发布负责人明明在旁路名单里，仍被要求走 PR

检查旁路模式是否设为 For pull requests only。这个模式允许角色绕过部分限制，但仍要求从 Pull Request 路径进入，适合保留审批和审计记录。如果确实需要完全旁路，应由团队明确批准后再调整。

看不到 Rulesets 或无法激活

先确认当前账号拥有仓库规则管理权限，再核对仓库可见性与所在组织的 GitHub 套餐。Rulesets 的可用范围与仓库类型、个人或组织套餐有关，权限不足时不要改用更宽松的临时分支保护绕过流程。

归档这次规则变更

规则集创建后，建议在仓库运维记录中保存六项信息：规则集名称、目标模式、Enforcement status、启用规则、状态检查名称、旁路角色或应用，以及本次变更原因。以后发布分支命名从单层调整为多层时，就能准确判断是修改 release/*，还是新增一个独立规则集，而不会靠猜测扩大保护范围。

最终判断标准很简单：详情页显示 release-branch-policy 为 Active，目标只含 release/* 或 release/**/*，发布分支受到预期保护，而 main、develop 和普通功能分支不受这套规则集影响。