规则集可用规则

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

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

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

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

限制创建

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

限制更新

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

限制删除

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

要求线性历史记录

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

在您可以要求线性提交历史记录之前，您的仓库必须允许 squash 合并或 rebase 合并。更多信息，请参阅“配置拉取请求合并”。

要求部署成功后才能合并

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

要求签署提交

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

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

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

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

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

合并前要求拉取请求

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

其他设置

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

如果您启用了必需的审核，协作者只能通过获得所需数量的具有写入权限的审核者批准的拉取请求来将更改推送到分支。

如果有人在审核中选择**请求更改**选项，则该人必须批准拉取请求才能合并拉取请求。如果请求拉取请求更改的审核者不可用，则任何具有仓库写入权限的人员都可以取消阻止审核。

即使所有必需的审核者都批准了拉取请求，如果还有其他打开的拉取请求的头部分支指向具有待处理或已拒绝审核的相同提交，协作者也无法合并拉取请求。具有写入权限的人员必须首先批准或取消其他拉取请求上的阻止审核。

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

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

您可以选择要求在合并拉取请求之前获得除最后一位向分支推送的人员以外的某人的批准。这意味着至少另一位授权的审核者已批准任何更改。例如，“最后一位审核者”可以检查最新的更改集是否包含来自其他审核的反馈，并且不添加新的、未经审核的内容。

对于需要多次审查的复杂拉取请求，要求除最后一次推送的人之外的其他人批准，可以作为一种折衷方案，避免需要驳回所有过时的审查：使用此选项，“过时”的审查不会被驳回，并且只要除最近更改的人之外的其他人批准，拉取请求仍然保持批准状态。已经审查过拉取请求的用户可以在最近一次推送后重新批准以满足此要求。如果您担心拉取请求被“劫持”（未经批准的内容被添加到已批准的拉取请求中），则驳回过时的审查更为安全。

或者，您可以在将拉取请求合并到分支之前，要求解决拉取请求上的所有评论。这确保在合并之前处理或确认所有评论。

合并前要求状态检查通过

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

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

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

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

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

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

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

设置代码扫描合并保护

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

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

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

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

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

阻止强制推送

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

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

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

限制文件路径

阻止包含指定文件路径中更改的提交被推送到代码库。

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

限制文件路径长度

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

限制文件扩展名

阻止包含具有指定文件扩展名的文件的提交被推送到代码库。

限制文件大小

阻止超过指定文件大小限制的提交被推送到代码库。