规则集的可用规则

您可以创建分支或标签规则集来控制用户如何与存储库中的选定分支和标签进行交互。您还可以创建推送规则集来阻止向私有或内部存储库及其整个分支网络推送。

创建规则集时，您可以允许某些用户绕过规则集中的规则。这些用户可以具有某些角色、特定团队或 GitHub 应用程序。

对于推送规则集，绕过权限适用于存储库及其整个分支网络。这意味着，对于此存储库整个分支网络中的任何存储库，只有能够绕过根存储库中此规则集的用户才能绕过此规则集。

有关创建规则集和绕过权限的更多信息，请参阅“为存储库创建规则集”。

限制创建

如果选中，则只有具有绕过权限的用户才能创建名称与您指定的模式匹配的分支或标签。

限制更新

如果选中，则只有具有绕过权限的用户才能推送至名称与您指定的模式匹配的分支或标签。

限制删除

如果选中，则只有具有绕过权限的用户才能删除名称与您指定的模式匹配的分支或标签。此规则默认选中。

要求线性历史记录

强制执行线性提交历史记录可防止协作者将合并提交推送到目标分支或标签。这意味着合并到分支或标签中的任何拉取请求都必须使用压缩合并或变基合并。严格的线性提交历史记录可以帮助团队更轻松地恢复更改。有关合并方法的更多信息，请参阅“关于拉取请求合并”。

在要求线性提交历史记录之前，您的存储库必须允许压缩合并或变基合并。有关更多信息，请参阅“配置拉取请求合并”。

要求部署在合并之前成功

您可以在合并分支之前要求将更改成功部署到特定环境。例如，您可以使用此规则来确保在将更改合并到默认分支之前，已成功将更改部署到暂存环境。

要求签名提交

在分支上启用必需的提交签名后，贡献者和机器人只能推送已签名并已验证到分支的提交。有关更多信息，请参阅“关于提交签名验证”。

创建分支时，分支保护规则和规则集的行为不同：对于规则集，我们只检查其他分支无法访问的提交，而对于分支保护规则，除非您限制创建匹配分支的推送，否则我们不会验证已签名的提交。对于这两种方法，当您更新分支时，我们仍会检查指定范围内的所有提交，即使从其他分支可以访问该提交。

对于这两种方法，我们使用 verified_signature? 来确认提交是否具有有效的签名。如果没有，则不接受更新。

如果提交已签名并经过验证，则您始终可以将本地提交推送到分支。您还可以在 GitHub 上使用拉取请求将已签名和已验证的提交合并到分支中。但是，除非您是拉取请求的作者，否则您无法在 GitHub 上将拉取请求压扁并合并到分支中。您可以在本地压扁并合并拉取请求。有关更多信息，请参阅“在本地签出拉取请求”。

有关合并方法的更多信息，请参阅“关于 GitHub 上的合并方法”。

合并前需要拉取请求

您可以要求对目标分支的所有更改都与拉取请求相关联。拉取请求不一定必须获得批准，但必须打开。

其他设置

具有“编辑存储库规则”权限的存储库管理员或自定义角色可以要求在有人将拉取请求合并到受保护分支之前，所有拉取请求都收到特定数量的批准审查。您可以要求存储库中具有写权限的人员或指定的代码所有者批准审查。

如果您启用必需审查，则合作者只能通过拉取请求将更改推送到分支，该拉取请求已获得具有写权限的必需数量的审阅者批准。

如果有人在审查中选择请求更改选项，则在合并拉取请求之前，该人必须批准拉取请求。如果请求拉取请求更改的审阅者不可用，则存储库的任何具有写权限的人都可以驳回阻止审查。

即使所有必需的审阅者都已批准拉取请求，如果还有其他未关闭的拉取请求，其头部分支指向具有待定或已拒绝审查的相同提交，则合作者也无法合并拉取请求。具有写权限的人员必须首先批准或驳回其他拉取请求上的阻止审查。

您还可以选择在影响拉取请求中差异的提交被推送时驳回过时的拉取请求批准。GitHub 在批准拉取请求时记录差异的状态。此状态表示审阅者批准的更改集。如果差异从此状态更改（例如，因为贡献者将新更改推送到拉取请求分支或单击更新分支，或因为相关的拉取请求被合并到目标分支中），则批准的审查将被驳回为过时，并且在有人再次批准该工作之前，无法合并拉取请求。有关目标分支分支的信息，请参阅“关于拉取请求”。

您还可以选择要求代码所有者进行审核。如果您这样做，则修改带代码所有者内容的任何拉取请求必须得到该代码所有者的批准，然后才能将拉取请求合并到受保护的分支中。请注意，如果代码有多个所有者，则任何代码所有者的批准就足以满足此要求。有关详细信息，请参阅“关于代码所有者”。

您还可以选择要求在拉取请求合并之前，由除最后一次推送到分支的人以外的人进行批准。这意味着至少有一位其他授权审阅者已批准任何更改。例如，“最后审阅者”可以检查最新一组更改是否纳入了其他审阅的反馈，并且没有添加新的未审阅的内容。

对于需要多次审阅的复杂拉取请求，要求除最后一次推送到分支的人以外的人进行批准可能是一种折衷方案，可以避免驳回所有陈旧的审阅：使用此选项，不会驳回“陈旧”的审阅，并且只要不是做出最近更改的人员批准拉取请求，拉取请求仍会得到批准。已审阅拉取请求的用户可以在最近一次推送后重新批准以满足此要求。如果您担心拉取请求被“劫持”（将未批准的内容添加到已批准的拉取请求中），则驳回陈旧的审阅会更安全。

您还可以选择要求在将拉取请求合并到分支之前解决所有对拉取请求的评论。这可确保在合并之前解决或确认所有评论。

要求在合并之前通过状态检查

必需的状态检查可确保在协作者对规则集针对的分支或标记进行更改之前，所有必需的 CI 测试都通过。必需的状态检查可以是检查或状态。有关详细信息，请参阅“关于状态检查”。

您可以使用提交状态 API 允许外部服务用适当的状态标记提交。有关详细信息，请参阅“提交状态的 REST API 端点”。

启用必需的状态检查后，在协作者可以将更改合并到分支或标记之前，所有必需的状态检查都必须通过。

任何具有对存储库的写权限的人员或集成都可以设置存储库中任何状态检查的状态，但在某些情况下，您可能只想接受来自特定 GitHub 应用的状态检查。当您添加必需的状态检查规则时，您可以选择一个应用作为状态更新的预期来源。该应用必须在存储库中安装，并具有statuses:write权限，必须最近提交过检查运行，并且必须与规则集中已存在的必需状态检查相关联。如果状态是由任何其他人或集成设置的，则不允许合并。如果您选择“任何来源”，您仍然可以在合并框中列出的每个状态的手动验证作者。

您可以将必需的状态检查视为“宽松”或“严格”。您选择的必需状态检查类型决定了在合并之前您的分支是否必须与基础分支保持最新。

必需状态检查类型	设置	合并要求	注意事项
严格	选中在合并前要求分支保持最新复选框。	在合并之前，主题分支必须与基础分支保持最新。	这是必需状态检查的默认行为。可能需要更多构建，因为在其他协作者更新目标分支后，您需要使头分支保持最新。
宽松	在合并前要求分支保持最新复选框未选中。	在合并之前，分支不必与基础分支保持最新。	您需要的构建更少，因为在其他协作者合并拉取请求后，您不必使头分支保持最新。如果与基础分支有不相容的更改，则在合并分支后状态检查可能会失败。
已禁用	在合并前要求状态检查通过复选框未选中。	该分支没有合并限制。	如果未启用必需的状态检查，则无论协作者是否与基础分支保持最新，他们都可以随时合并该分支。这增加了不相容更改的可能性。

有关故障排除信息，请参见“必需状态检查故障排除”。

设置代码扫描合并保护

如果您的存储库配置了代码扫描，则可以使用规则集来防止在满足以下条件之一时合并拉取请求

• 必需的工具发现了规则集中定义的严重性代码扫描警报。

• 必需的代码扫描工具的分析仍在进行中。

• 为存储库未配置必需的代码扫描工具。

有关更多信息，请参见“设置代码扫描合并保护”。有关代码扫描的更多一般信息，请参见“关于代码扫描”。

阻止强制推送

您可以阻止用户对目标分支或标签执行强制推送。此规则默认启用。

如果有人对分支或标签执行强制推送，则其他协作者基于其工作的提交可能会从分支或标签的历史记录中删除。这可能导致合并冲突或损坏的拉取请求。强制推送还可用于删除分支或将分支指向未在拉取请求中批准的提交。

启用强制推送不会覆盖任何其他规则。例如，如果某个分支需要线性提交历史记录，则不能强制推送合并提交到该分支。

限制文件路径

防止包含指定文件路径中更改的提交被推送到存储库。

你可以为此使用 fnmatch 语法。例如，针对 test/demo/**/* 的限制会阻止对 test/demo/ 目录中的文件或文件夹进行任何推送。针对 test/docs/pushrules.md 的限制会阻止专门针对 test/docs/ 目录中的 pushrules.md 文件进行推送。有关更多信息，请参阅“为存储库创建规则集”。

限制文件路径长度

防止包含超过指定字符限制的文件路径的提交被推送到存储库。

限制文件扩展名

防止包含具有指定文件扩展名的文件的提交被推送到存储库。

限制文件大小

防止超过指定文件大小限制的提交被推送到存储库。