关于分支保护规则
您可以通过创建分支保护规则，实施某些工作流程或要求，以规定协作者如何向您仓库中的分支推送更改，包括将拉取请求合并到分支。 仅当存储库属于组织时，才能将参与者添加到绕过列表。
默认情况下，每个分支保护规则都禁止强制推送到匹配的分支并阻止删除匹配的分支。 您可以选择禁用这些限制并启用其他分支保护设置。
默认情况下，分支保护规则的限制不适用于对存储库具有管理员权限的人员或具有“绕过分支保护”权限的自定义角色。 也可以选择将限制应用于具有“绕过分支保护”权限的管理员和角色。 有关详细信息，请参阅“管理组织的自定义存储库角色”。
可以在存储库中为特定分支、所有分支或者与使用 fnmatch 语法指定的命名模式匹配的任何分支创建分支保护规则。 例如，若要保护包含单词 release 的任何分支，可以为 *release* 创建分支规则。 有关分支名称模式的详细信息，请参阅“管理分支保护规则”。
您可以配置拉取请求在满足所有合并要求时自动合并。 有关详细信息，请参阅“自动合并拉取请求”。
注意：一次只能应用一个分支保护规则，这意味着当一个规则的多个版本面向同一分支时，很难知道将应用哪个规则。 此外，你可能想要创建一组适用于组织中多个存储库的规则。 有关分支保护规则的替代方法信息，请参阅“关于规则集”。
关于分支保护设置
对于每个分支保护规则，您可以选择启用或禁用以下设置。
- 在合并前需要拉取请求审查
- 合并前必需状态检查
- 合并前需要对话解决
- 需要签名提交
- 需要线性历史记录
- 需要合并队列
- 要求部署成功后才能合并
- 锁定分支
- 不允许绕过上述设置
- 限制可推送到匹配分支的人员
- 允许强制推送
- 允许删除
有关如何设置分支保护的详细信息，请参阅“管理分支保护规则”。
合并前必需拉取请求审查
存储库管理员或具有“编辑存储库规则”权限的自定义角色可以要求所有拉取请求在有人将拉取请求合并到受保护的分支之前接收特定数量的审批评审。 您可以要求仓库中具有写入权限的人或指定代码所有者批准审查。
如果启用必需审查，则协作者只能通过由所需数量的具有写入权限之审查者批准的拉取请求向受保护分支推送更改。
如果某个具有管理员权限的人员在审查中选择“请求更改”选项，则拉取请求必须经此人批准后才可合并。 如果申请更改拉取请求的审查者没有空，则具有仓库写入权限的任何人都可忽略阻止审查。
即使在所有必需的审查者已经批准拉取请求之后，如果还有其他打开的拉取请求有头部分支指向同一待处理或拒绝审查的评论，协作者也不能合并拉请求。 具有写入权限的人必须先批准或取消对其他拉取请求的阻止审查。
如果协作者尝试将待处理或被拒绝审查的拉取请求合并到受保护分支，则该协作者将收到错误消息。
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.
（可选）可以选择在推送影响拉取请求差异的提交时关闭过时的拉取请求审批。 GitHub 记录拉取请求获得批准时的差异状态。 此状态表示审阅者批准的一组更改。 如果差异从此状态发生变化（例如，因为参与者将新更改推送到拉取请求分支或单击“更新分支”，或者因为相关拉取请求已合并到目标分支），则审批评审会因过时而被关闭，并且在有人再次批准该工作之前无法合并拉取请求。 有关基分支的信息，请参阅“关于拉取请求”。
（可选）您可以限制特定人员或团队忽略拉取请求审查的权限。 有关详细信息，请参阅“忽略拉取请求审查”。
（可选）您可以选择要求代码所有者进行审查。 如果这样做，则任何影响代码的拉取请求都必须得到代码所有者的批准，才能合并到受保护分支。
（可选）可以要求最近的可评审推送必须得到推送者以外的其他人的批准。 这意味着至少有一位其他授权审阅者已批准了任何更改。 例如，“最后一位审阅者”可以检查最新的一组更改是否包含来自其他评审的反馈，并且未添加新的、未经评审的内容。
对于需要多次评审的复杂拉取请求，要求最后一位推送者以外的其他人的批准是一种折中操作，这样无需关闭所有过时的评审：使用此选项时，“过时”的评审不会被关闭，并且只要进行最新更改的人以外的其他人批准了拉取请求，该拉取请求就会保持批准状态。 已审查过拉取请求的用户可以在最近一次推送后重新批准，以满足此要求。 如果担心拉取请求被“劫持”（将未经批准的内容添加到已批准的拉取请求中），则更安全的做法是关闭过时的评论。
Note
如果选择“推送新提交时关闭旧拉取请求审批”和/或“需要审批最近的可评审推送”，则手动为拉取请求创建合并提交并将其直接推送到受保护分支的操作将失败，除非合并内容与 GitHub 为拉取请求生成的合并完全匹配。
此外，使用这些设置，如果合并基在提交评审后引入新更改，审批评审将因过时而被关闭。 合并基础是主题分支和基础分支之间的最后一个共同上级的提交。 如果合并基发生更改，则拉取请求在再次审批工作之前无法合并。
合并前必需状态检查
必需状态检查确保在协作者可以对受保护分支进行更改前，要么已通过要么已跳过所有必需的 CI 测试。 更多信息请参阅“配置受保护分支”和“启用必需状态检查”。 有关详细信息，请参阅“关于状态检查”。
可以使用提交状态 API 让外部服务能够将提交标记为适当的状态。 有关详细信息，请参阅“适用于提交状态的 REST API 终结点”。
启用必需状态检查后，必须通过所有必需状态检查，协作者才能将更改合并到受保护分支。 所有必需状态检查通过后，必须将任何提交推送到另一个分支，然后合并或直接推送到受保护分支。
任何对存储库具有写入权限的人员或集成都可以在存储库中设置任何状态检查的状态，但在某些情况下，你可能只想接受来自特定 GitHub App 的状态检查。 添加所需的状态检查时，可以选择最近将此检查设置为预期状态更新源的应用。 如果状态由任何其他人员或集成设置，则无法合并。 如果选择“任何来源”，您仍然可以手动验证合并框中列出的每个状态的作者。
您可以将必需状态检查设置为“宽松”或“严格”。 您选择的必需状态检查类型确定合并之前是否需要使用基础分支将您的分支保持最新状态。
| 必需状态检查的类型 | 设置 | 合并要求 | 注意事项 |
|---|---|---|---|
| Strict | 选中“合并前要求分支保持最新状态”复选框。 | 在合并之前，必须利用基分支使分支保持最新状态。 | 这是必需状态检查的默认行为。 可能需要更多构建，因为在其他协作者更新目标分支后，你需要使头部分支保持最新状态。 |
| 宽松 | 未选中“合并前要求分支保持最新状态”复选框 。 | 在合并之前，不必利用基分支使分支保持最新状态。 | 您将需要更少的构建，因为在其他协作者合并拉取请求后，您不需要使头部分支保持最新状态。 如果存在与基础分支不兼容的变更，则在合并分支后，状态检查可能会失败。 |
| 已禁用 | 未选中“合并前要求通过状态检查”复选框 。 | 分支没有合并限制。 | 如果未启用必需状态检查，协作者可以随时合并分支，无论它是否使用基础分支保持最新状态。 这增加了不兼容变更的可能性。 |
有关故障排除信息，请参阅“必需状态检查故障排除”。
合并前需要对话解决
在合并到受保护的分支之前，所有对拉取请求的评论都需要解决。 这确保所有评论在合并前都得到解决或确认。
要求签名提交
如果你在分支上启用所需的提交签名，参与者和机器人只能将已签名和验证的提交推送到分支。 有关详细信息，请参阅“关于提交签名验证”。
注意：
- 如果您已经启用了警戒模式，这表明您的提交总是会签名，允许在需要签名提交的分支上提交 GitHub 识别为“部分验证”的任何提交。 有关警戒模式的详细信息，请参阅“显示所有提交的验证状态”。
- 如果协作者将未签名的提交推送到要求提交签名的分支，则协作者需要变基提交以包含验证的签名，然后将重写的提交强制推送到分支。
如果提交已进行签名和验证，则始终可以将本地提交推送到分支。 你也可以使用 GitHub Enterprise Cloud 上的拉取请求将已签名和验证的提交合并到分支。 但除非你是拉取请求的作者，否则不能将拉取请求压缩并合并到 GitHub Enterprise Cloud 上的分支。 你可以在本地压缩和合并拉取请求。 有关详细信息，请参阅“本地检查拉取请求”。
有关合并方法的详细信息，请参阅“关于 GitHub 上的合并方法”。
需要线性历史记录
强制实施线性提交历史记录可阻止协作者将合并提交推送到分支。 这意味着合并到受保护分支的任何拉取请求都必须使用压缩合并或变基合并。 严格的线性提交历史记录可以帮助团队更容易回溯更改。 有关合并方法的详细信息，请参阅“关于拉取请求合并”。
在需要线性提交历史记录之前，仓库必须允许压缩合并或变基合并。 有关详细信息，请参阅“配置拉取请求合并”。
需要合并队列
合并队列通过将拉取请求自动合并到繁忙的分支中，并确保分支永远不会因不兼容的更改而中断，从而帮助提高速度。
合并队列提供与“要求分支在合并之前保持最新”分支保护相同的优势，但不需要拉取请求作者在尝试合并之前，更新其拉取请求分支并等待状态检查完成。
如果分支具有每天从许多不同用户合并的大量拉取请求，那么使用合并队列特别有用。
拉取请求通过所有必需的分支保护检查后，对存储库具有写入访问权限的用户可以将该拉取请求添加到该队列。 合并队列将确保拉取请求的更改在应用于最新版本的目标分支和队列中已有的任何拉取请求时通过所有必需的状态检查。
合并队列可以使用 GitHub Actions 或你自己的 CI 提供程序对合并队列中的拉取请求运行所需的检查。 有关详细信息，请参阅“GitHub Actions 文档”。
一旦通过了所有必需的 CI 检查，GitHub Enterprise Cloud 将根据分支保护中配置的合并策略合并拉取请求。 有关合并队列的详细信息，请参阅“管理合并队列”。
在合并前要求部署成功
在合并分支之前，可以要求将更改成功部署到特定环境。 例如，可以使用此规则确保在更改合并到默认分支之前成功部署到过渡环境。
锁定分支
锁定分支将分支设为只读，确保无法对分支进行任何提交。 锁定的分支同样无法删除。
默认情况下，分支存储库不支持从其上游存储库同步。 可以启用“允许分支同步”以从上游存储库中提取更改，同时阻止对分叉分支的其他贡献。
不允许避开上述设置
默认情况下，分支保护规则的限制不适用于对存储库具有管理员权限的人员或在存储库中具有“绕过分支保护”权限的自定义角色。
也可以启用此设置以将限制应用于具有“绕过分支保护”权限的管理员和角色。 有关详细信息，请参阅“管理组织的自定义存储库角色”。
限制谁可以推送到匹配的分支
可以在 GitHub Free 组织拥有的公共存储库，以及使用 GitHub Team 或 GitHub Enterprise Cloud 的组织拥有的所有存储库中启用分支限制。
启用分支限制时，只有已授予权限的用户、团队或应用程序才能推送到受保护的分支。 您可以在受保护分支的设置中查看和编辑对受保护分支具有推送权限的用户、团队或应用程序。 当需要状态检查时，如果所需的检查失败，仍会阻止有权推送到受保护分支的人员、团队和应用合并为一个分支。 当需要拉取请求时，有权推送到受保护分支的人员、团队和应用仍需要创建拉取请求。
（可选）可以将相同的限制应用于创建与规则匹配的分支。 例如，如果创建一个仅允许特定团队推送到包含单词 release 的任何分支的规则，则只有该团队的成员才能创建包含单词 release 的新分支。
只能向对存储库具有写入权限的用户、团队或已安装的 GitHub Apps 授予推送到受保护分支或创建匹配分支的权限。 对存储库具有管理员权限的人员和应用程序始终能够推送到受保护分支或创建匹配分支。
允许强制推送
默认情况下，GitHub Enterprise Cloud 会阻止对所有受保护分支的强制推送。 启用强制推送到受保护分支时，可以选择两个可以强制推送的组之一：
- 允许至少具有存储库写入权限的每个人强制推送到分支，包括具有管理员权限的人员。
- 仅允许特定人员或团队强制推送到分支。
如果有人强制推送到分支，则强制推送可能会导致从分支的历史记录中删除其他协作者基于其工作的提交。 用户可能有合并冲突或损坏的拉取请求。 强制推送还可用于删除分支或将分支指向未在拉取请求中批准的提交。
启用强制推送不会覆盖任何其他分支保护规则。 例如，如果分支需要线性提交历史记录，则无法强制推送合并提交到该分支。
允许删除
默认情况下，您不能删除受保护的分支。 启用删除受保护分支后，任何对仓库至少拥有写入权限的人都可以删除分支。
注意：**** 如果分支已锁定，即使你有权删除分支，也无法将其删除。