GitHub 如何在仓库设置中启用分支保护规则：从规则入口到保存校验

团队希望把 main 变成“必须经过 Pull Request 审查才能合并”的稳定分支时，GitHub 的分支保护规则就是对应入口。实际操作不在仓库首页的 Code 页面完成，而是从 Settings 进入 Code and automation 下的 Branches，再创建针对 main 的规则。

这次任务要保护什么

下面用一个最小任务说明路径：保护默认分支 main，要求合并前至少得到一次 Pull Request 审查，并保留状态检查、线性历史等选项的按需配置。GitHub 官方文档说明，分支保护可以作用于单个分支、所有分支或符合 fnmatch 模式的分支；创建和管理通常需要仓库管理员权限或自定义角色的 edit repository rules 权限。

步骤一：从仓库首页进入 Settings

打开目标仓库主页，在仓库名称下方的标签栏点击 Settings。如果横向空间不足，先打开更多标签的下拉菜单，再选择 Settings。不要把个人账户的 Settings 当成仓库设置；分支规则必须在具体仓库的上下文里配置。

看到仓库级设置侧栏后再继续。若没有 Settings，先检查当前账户是否对该仓库拥有管理权限；缺少权限时继续寻找按钮不会解决问题。

步骤二：在 Code and automation 中选择 Branches

在 Settings 左侧找到 Code and automation 分组，点击 Branches。GitHub 当前侧栏还会显示 Rules 分组和 Rulesets 子项，但它属于规则集功能；本次任务采用传统的 branch protection rule，所以入口应保持为 Branches。

成功状态是主区域出现 Branches 页面，并能看到现有规则列表或创建规则的按钮。若侧栏只有 Rulesets 而没有 Branches，先核对仓库类型、套餐和当前权限，不要把规则集页面当作传统规则编辑页。

步骤三：为 main 填写规则边界

在 Branches 页面找到分支保护规则区域，点击创建新规则的按钮，在分支名称模式中填写 main。如果目标是多个发布分支，才使用类似 release/* 的模式；不要为了省事直接选择所有分支，否则新建临时分支也可能被同一套合并门槛拦住。

接着按任务选择规则：勾选 Require a pull request before merging，将必需批准数设为 1；如果仓库已有稳定的 CI 检查，再勾选 Require status checks to pass before merging 并选择具体检查项。是否启用 Require conversation resolution、Require signed commits、Require linear history、Allow force pushes 和 Allow deletions，应根据仓库治理要求逐项决定，不要把所有开关当成默认必选项。

每次勾选后都检查它是否展开了附加字段：状态检查必须选到具体检查名称，审查规则要确认批准数，推送限制要确认允许主体。关键成功状态是表单中仍显示目标模式 main，且选中的要求保持勾选。

步骤四：保存并回到列表验收

完成规则选择后点击 Create 或页面对应的保存按钮。保存动作结束后回到 Branches 列表，确认规则摘要显示 main，并能看到 Pull Request review 或 status checks 等已启用的要求。若列表没有新增规则，优先检查是否缺少管理员权限、分支模式为空，或提交按钮仍处于不可用状态。

验收不要只看“页面跳回去了”：从规则右侧的编辑入口重新打开，核对批准数量和状态检查名称，再用一个测试 Pull Request 验证合并按钮是否按预期被保护规则约束。测试完成后不要为了验证而启用 Allow force pushes 或 Allow deletions。

常见问题与边界

为什么看不到 Settings 或 Branches？

分支保护规则需要仓库管理员权限，或自定义角色中包含 edit repository rules 权限。公开仓库与不同 GitHub 套餐的可用范围也不同；先让仓库管理员确认权限和套餐，再判断是否是界面路径问题。

Branches 和 Rulesets 应该选哪个？

只需要一个传统的分支保护规则时选 Branches；需要多个规则同时作用于同一分支、需要更细的目标匹配或规则集状态时，再评估 Rulesets。两者可以同时存在，不能把一个页面里的开关当成另一个页面的保存结果。

为什么状态检查已勾选却没有阻止合并？

检查名称必须与工作流实际产生的检查项一致，而且需要在规则中完成选择。回到规则编辑页核对名称，再从 Pull Request 的 Checks 区域确认该检查真的运行并通过。

最终确认清单

• 仓库首页的 Settings 已进入，而不是账户级设置。
• 路径为 Code and automation → Branches，目标模式明确写成 main。
• 审查、状态检查和其他规则只启用了当前仓库真正需要的选项。
• 保存后从规则列表和测试 Pull Request 两处确认保护已经生效。