规则集可用规则 - GitHub 文档

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

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

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

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

限制删除

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

要求线性历史

强制使用线性提交历史可防止协作者向目标分支或标签推送合并提交。这意味着任何合并到该分支或标签的拉取请求必须使用“压缩合并”（squash）或“变基合并”（rebase）方式。严格的线性提交历史有助于团队更容易地回滚更改。有关合并方式的更多信息，请参阅关于拉取请求的合并方式。

在要求线性提交历史之前，您的仓库必须允许压缩合并或变基合并。有关详细信息，请参阅配置拉取请求合并。

合并前要求部署成功

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

要求签名提交

启用分支的必需提交签名后，贡献者和机器人只能向该分支推送已签名且已验证的提交。有关详细信息，请参阅关于提交签名验证。

分支保护规则和规则集在创建分支时的行为不同：使用规则集时，只检查那些不从其他分支可达的提交；而使用分支保护规则时，除非您限制了创建匹配分支的推送，否则不验证签名提交。两者在更新分支时，仍会检查指定范围内的所有提交，即使该提交可从其他分支访问。

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

注意

如果您在账户设置中启用了“警惕模式”，即您的提交始终会被签名，GitHub 将“部分验证”的提交视为允许在要求签名提交的分支上进行。有关警惕模式的更多信息，请参阅显示所有提交的验证状态。
如果协作者向需要签名的分支推送未签名的提交，协作者需要对该提交进行 rebase，以加入已验证的签名，然后强制推送改写后的提交到分支。

只要提交已签名并通过验证，您始终可以将本地提交推送到该分支。您也可以通过拉取请求将已签名且已验证的提交合并到分支。但是，除非您是该拉取请求的作者，否则无法在 GitHub 上使用“压缩并合并”。您可以在本地执行压缩合并。有关详细信息，请参阅在本地检出拉取请求。

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

合并前要求拉取请求

您可以要求对目标分支的所有更改都必须关联到拉取请求。该拉取请求不一定需要批准，但必须处于打开状态。

其他设置

注意

如果您选择 在推送新提交时撤销陈旧的拉取请求批准 和/或 要求对最近可审查的推送进行批准，则手动创建合并提交并直接推送到受保护分支将会失败，除非合并内容与 GitHub 为该拉取请求生成的合并完全一致。

此外，使用这些设置时，如果在提交审查后合并基发生了新更改，批准的审查将被视为陈旧并被撤销。合并基是主题分支和基分支之间的最后共同祖先。如果合并基变化，拉取请求必须重新获得批准才能合并。

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

如果启用必需审查，协作者只能通过已获写入权限审查者批准的拉取请求来向分支推送更改。

如果审查者在审查时选择了请求更改，则该审查者必须在拉取请求合并前再次批准该请求。如果发出“请求更改”的审查者不可用，拥有仓库写入权限的任何人都可以驳回该阻塞审查。

即使所有必需审查者已批准拉取请求，只要还有其他打开的拉取请求的头分支指向相同提交且仍有待审或被拒的审查，协作者仍不能合并。必须先让拥有写入权限的人员批准或驳回这些其他拉取请求的阻塞审查。

您可以选择在推送影响拉取请求差异的提交时，驳回过时的拉取请求批准。GitHub 会记录拉取请求获得批准时的差异状态，该状态代表审查者批准的更改集合。如果差异相对于该状态发生变化（例如贡献者向拉取请求分支推送了新更改、点击了更新分支，或相关拉取请求已合并到目标分支），则该批准审查会被标记为过时并被驳回，拉取请求必须重新获得批准后才可合并。有关目标分支的更多信息，请参阅关于拉取请求。

您可以选择要求代码所有者的审查。如果启用此项，任何修改了代码所有者负责的内容的拉取请求，都必须得到该代码所有者的批准后才能合并到受保护分支。需要注意的是，如果同一代码有多个所有者，只要得到其中 **任意** 一个所有者的批准，即可满足此要求。更多信息请参阅关于代码所有者。

您可以要求在拉取请求合并之前，必须获得除最后一次推送分支的人员之外的其他人的批准。这意味着至少还有一位有授权的审查者批准了更改。例如，最后的审查者可以检查最新一轮更改是否已采纳其他审查的反馈，并且没有添加未经审查的新内容。

对于需要大量审查的复杂拉取请求，要求“除最后一次推送者之外的其他人批准”是一种折中方案，可避免必须驳回所有过时审查的情况：使用此选项时，“过时”的审查不会被驳回，只要除最近一次推送者之外的其他人批准，拉取请求仍保持已批准状态。已经审查过的用户可以在最新一次推送后再次批准，以满足此要求。如果您担心拉取请求被“劫持”（即在已批准的拉取请求中加入未经批准的内容），则更安全的做法是驳回过时审查。

您可以要求在拉取请求合并之前，所有评论都已解决。这样可确保在合并前所有评论都已得到处理或确认。

您可以要求使用合并、压缩或变基的合并类型。这意味着目标分支只能使用允许的方式进行合并。如果仓库已禁用某种合并方式，而规则集要求使用该方式，则合并将被阻止。请参阅关于 GitHub 上的合并方式。

必需审查者

您可以在拉取请求修改特定文件或目录时，要求来自特定团队的审查或批准。最多可以指定 15 个不同的团队，并且可以为每个团队设置所需的批准人数。

Reviewer 下拉列表允许您选择规则定义范围内的任意团队。

组织范围规则：团队必须属于该组织。
仓库级别规则：团队必须属于拥有该仓库的组织。

此规则在用户拥有的仓库上不可用，因为用户仓库不包含团队。

必需的批准人数可以设置为 0 到 10。设置为 0 表示该团队仅用于可见性，团队成员无需实际批准请求。

对于每个团队，您可以指定一组文件模式，以决定该设置适用于哪些文件。该文件列表的格式与标准的 .gitignore 文件相同。

以感叹号 (!) 开头的模式表示取反。这将导致匹配早先模式的路径不需要批准。
模式按顺序匹配，因此取反模式可以“取消匹配”之前规则匹配的文件。

合并前要求状态检查通过

必需的状态检查可确保在协作者对规则集目标的分支或标签进行更改之前，所有必需的 CI 测试均已通过。必需的状态检查可以是检查（checks）或状态（statuses）。有关详细信息，请参阅关于状态检查。

您可以使用提交状态 API 让外部服务为提交标记合适的状态。详情请参阅提交状态的 REST API 端点。

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

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

如需排查规则集中的状态检查配置问题，请参阅规则故障排除。

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

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

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

阻止强制推送

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

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

启用强制推送不会覆盖其他规则。例如，如果分支要求线性提交历史，则您不能对该分支进行强制推送合并提交。

要求代码扫描结果

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

必需的工具发现了规则集中定义的严重程度的代码扫描警报。
必需的工具仍在进行分析。
必需的工具未为该仓库配置。

更多信息请参阅设置代码扫描合并保护。有关代码扫描的概览，请参阅关于代码扫描。

要求代码质量结果

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

分析仍在进行中。
分析因任何原因失败，例如：已耗尽 Action 分钟配额。
代码质量检测到规则集中定义或更高级别的严重性结果。

更多信息请参阅关于 GitHub 代码质量与为拉取请求设置代码质量阈值。

规则集的可用规则

谁可以使用此功能？

本文内容

限制创建

限制更新