规则集的可用规则

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

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

对于推送规则集，旁路权限会应用于存储库和存储库的整个分支网络。这意味着，在此存储库的整个分支网络中，唯一可以绕过此规则集的用户是在根存储库中可以绕过此规则集的用户。

有关创建规则集和绕过权限的详细信息，请参阅创建存储库的规则集。

限制删除

如果选中，则只有具有绕过权限的用户才能删除名称与指定模式匹配的分支或标记。默认情况下，此规则处于选中状态。

需要线性历史记录

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

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

在合并前要求部署成功

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

要求签名提交

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

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

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

注意

如果你已在帐户设置中启用警惕模式，这表明你的提交将始终带有签名，那么，在要求提交带有签名的分支上，任何被 GitHub 识别为“部分已验证”的提交都是允许的。有关警戒模式的详细信息，请参阅显示所有提交的验证状态。
如果协作者将未签名的提交推送到要求提交签名的分支，则协作者需要变基提交以包含验证的签名，然后将重写的提交强制推送到分支。

如果提交已签名并已验证，则可以将本地提交推送到分支。

还可以使用拉取请求将已签名和已验证的提交合并到分支中。当 GitHub 评估拉取请求是否可以合并时，它会创建一个测试合并提交，该提交的父提交为基础分支上的最新提交和拉取请求的头提交。 GitHub 检查此测试合并引入的提交，包括来自头分支的提交。因此，头分支上的未签名提交可能会阻止壁球合并，即使 GitHub 对最终的壁球提交进行签名也是如此。此限制也适用于拉取请求的作者。

若要合并被阻止的拉取请求，请重写头分支上的未签名提交并为其签名，或请有权绕过相应保护规则的人员来合并该拉取请求。

可以在本地对拉取请求进行挤压和合并，但必须在将请求推送到分支之前对生成的提交进行签名。如果另一项保护规则要求必须通过拉取请求进行更改，你可能还需要具备绕过该限制的权限，才能推送在本地合并后生成的提交。请参阅在本地检查拉取请求和对提交签名。

有关合并方法的详细信息，请参阅关于GitHub上的合并方法。

在合并前需要拉取请求

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

其他设置

注意

如果选择“推送新提交时关闭旧拉取请求审批”和/或“需要审批最近的可评审推送”，则手动为拉取请求创建合并提交并将其直接推送到受保护分支的操作将失败，除非合并内容与 GitHub 为拉取请求生成的合并完全匹配。

此外，使用这些设置，如果合并基在提交评审后引入新更改，审批评审将因过时而被关闭。合并基础是主题分支和基础分支之间的最后一个共同上级的提交。如果合并基发生更改，则拉取请求在再次审批工作之前无法合并。

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

如果启用必需的审查，则协作者只能通过由所需数量的具有写入权限的审查者批准的拉取请求向分支推送更改。

如果某人在审查中选择“请求更改”**** 选项，则拉取请求必须经此人批准后才可合并。如果申请更改拉取请求的审查者没有空，则具有存储库写入权限的任何人都可忽略阻止审查。

即使在所有必需的审查者已经批准拉取请求之后，如果还有其他打开的拉取请求有头部分支指向同一待处理或拒绝审查的评论，协作者也不能合并拉请求。具有写入权限的人必须先批准或取消对其他拉取请求的阻止审查。

（可选）可以选择在推送影响拉取请求差异的提交时关闭过时的拉取请求审批。 GitHub 会记录拉取请求获批时差异的状态。此状态表示审阅者批准的一组更改。如果差异从此状态发生变化（例如，因为参与者将新更改推送到拉取请求分支或单击“更新分支”****，或者因为有相关拉取请求合并到目标分支），则审批评审会因过时而被关闭，并且在有人再次批准该工作之前无法合并拉取请求。有关目标分支的信息，请参阅拉取请求。

（可选）你可以选择要求代码所有者进行审查。如果这样做，则任何修改内容的拉取请求都必须得到代码所有者的批准，才能合并到受保护分支。请注意，如果代码具有多个所有者，则任何代码所有者的批准均足以满足此要求。__ 有关详细信息，请参阅“关于代码所有者”。

你也可以选择限制哪些人可以驳回拉取请求的评审。如果启用此设置，请选择可以在被规则集定位的分支上关闭评审的用户、团队或 GitHub Apps。可以在 UI 中或通过 REST API 或 GraphQL API 配置此设置。有关详细信息，请参阅“忽略拉取请求审查”。

（可选）在合并拉取请求之前，可以需要除最后一个人以外的其他人的批准才能推送到分支。这意味着至少有一位获得授权的其他审阅者已批准了任何更改。例如，“最后一位审阅者”可以检查最新的一组更改是否包含来自其他评审的反馈，并且未添加新的、未经评审的内容。

对于需要多次评审的复杂拉取请求，要求最后一位推送者以外的其他人的批准是一种折中操作，这样无需关闭所有过时的评审：使用此选项时，“过时”的评审不会被关闭，并且只要进行最新更改的人以外的其他人批准了拉取请求，该拉取请求就会保持批准状态。已审查过拉取请求的用户可以在最近一次推送后重新批准，以满足此要求。如果担心拉取请求被“劫持”（将未经批准的内容添加到已批准的拉取请求中），则更安全的做法是关闭过时的评论。

或者，可以要求必须解决所有对拉取请求的注释才能将其合并到受保护的分支。这确保所有评论在合并前都得到解决或确认。

您还可以选择要求合并类型为合并、压扁或重置。这意味着目标分支只能根据允许的类型进行合并。此外，如果存储库禁用了一种合并方法，而规则集要求使用另一种方法，合并将被阻止。请参阅“关于GitHub上的合并方法”。

对无归属的 Copilot 拉取请求的额外批准

注意

此功能目前处于公开预览，可能会发生更改。

默认情况下，对新规则和现有规则集都启用对无归属的 Copilot 拉取请求需要额外批准。当 Copilot 打开未归属于某人的拉取请求时，规则集需要的批准数比你配置的数量多一个。例如，规则集若要求一次审批，则需要两次来自具有写入权限的人员的审批。

要求一次审批通常意味着一次变更会涉及两个人：提交该变更的人和批准该变更的人。当 Copilot 以自己的应用标识而不是代表某人打开拉取请求时，该假设不成立，例如当你从共享上下文（如群组线程或频道）提示它时。请参阅将 Copilot 云代理与 Slack 集成和将 Copilot 云代理与 Teams 集成。

如果规则集需要零个批准，此设置无效，因此将拉取请求用作更改记录而不是用于批准把关的存储库不受影响。

如果清除此设置，这些拉取请求仅需要你配置的批准数。如果你还要求由最后一次推送者以外的其他人提供批准，则至少必须有一项批准既涵盖最后一次推送，又来自Copilot以外的其他人。

需要的审查者

（可选）当拉取请求更改某些文件或目录时，你可以要求特定团队审阅或批准。最多可以指定 15 个不同的团队，并且对于每个团队，可能需要团队成员的一定数量的批准。若要使团队成员的批准被计入，团队必须对该仓库具有写入权限（或更高权限）。

通过审阅者下拉列表，您可以选择在定义规则的有效范围内的任何团队。

组织范围规则：团队必须属于组织。
存储库级规则：团队必须属于拥有存储库的组织。

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

所需的审批可以从 0（零）设置为 10。要求零审批意味着将添加团队以提高可见性，但团队不需要批准请求。

对于每个团队，可以指定文件模式列表，用于确定设置适用的文件。此文件列表的格式与标准 .gitignore 文件相同：

从感叹号（!）开始的模式是否定。这将导致与早期模式匹配的路径 不需要 审批。
模式按顺序进行匹配，因此否定模式可以取消与先前规则匹配的文件的匹配。

要求合并前必须通过状态检查

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

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

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

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

要排查在规则集中配置状态检查的问题，请参阅“排查规则”。

可以将必需的状态检查视为“宽松”或“严格”。你选择的必需状态检查类型确定合并之前是否需要使用基础分支将你的分支保持最新状态。

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

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

阻止强制推送

可以阻止用户强制推送到目标分支或标记。默认情况下，此规则处于启用状态。

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

注意

如果阻止强制推送，则除非有权绕过规则集，否则组织所有者或存储库管理员将无法更改或重命名默认分支。

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

需要 secret scanning 解决警报

注意

The rule to require secret scanning alerts to be resolved before merging is in 公开预览 and subject to change.

如果存储库使用 secret scanning，可以在以下任一条件适用时阻止拉取请求合并：

针对该拉取请求的头提交的 secret scanning 扫描尚未完成。
拉取请求中的某次提交引入了一个未处理的 secret scanning 警报，该警报与规则集中所选的机密类型相匹配。

可以为提供程序、自定义模式和泛型模式配置规则。不支持由 AI 检测到的机密信息。

有关详细信息，请参阅“Blocking pull request merges that contain secrets”。

要求 code scanning 结果

如果存储库已配置 code scanning，则可以使用规则集阻止在满足以下条件之一时合并拉取请求：

某个必需的工具发现了一个 code scanning 警报，且该警报的严重程度符合规则集中的定义。
所需的工具分析仍在进行中。
未为存储库配置所需的工具。

有关详细信息，请参阅“设置代码扫描合并保护”。有关 code scanning 的更多常规信息，请参阅代码扫描。

要求代码质量结果

如果存储库已配置 GitHub Code Quality，则可以使用规则集阻止在满足以下条件之一时合并拉取请求：

分析仍在进行中。
分析因任何原因而失败，例如：您的操作分钟预算已耗尽。
Code Quality 发现了一个严重性级别与规则集定义一致或更高的结果。

有关详细信息，请参阅 GitHub 代码质量和为拉取请求设置代码质量阈值。

合并前需要提供许可证合规性结果

这将在目标存储库上启用许可证合规性功能。许可证合规性检查会根据允许的许可证策略检查新增或更改的依赖项，并阻止添加了许可证不被允许的依赖项的拉取请求。有关详细信息，请参阅“关于开源许可证合规”。

限制代码覆盖率

注意

此功能目前处于公开预览，可能会发生更改。

如果你的仓库已启用 GitHub Code Quality 并且正在上传代码覆盖率数据，则可以使用规则集根据代码覆盖率阈值阻止合并拉取请求。有关上传覆盖范围数据的详细信息，请参阅为存储库设置代码覆盖率。

该规则仅评估已上传的覆盖率数据，不会等待覆盖率数据上传完成。为确保在合并拉取请求之前评估所有预期的覆盖率结果，请将与预期覆盖率上传相关联的每个状态检查都设为必需状态检查。

如果未满足两个代码覆盖率阈值之一，此规则将阻止拉取请求合并：

最小行覆盖率百分比：请求请求分支的聚合行覆盖率低于配置的百分比。
最大行覆盖率下降：与默认分支相比，行覆盖率下降超过已配置的百分点数。

有关如何配置阈值、上传覆盖范围数据的先决条件以及如何安全地推出规则，请参阅为拉取请求设置代码覆盖率阈值。

限制文件路径

阻止将包含指定文件路径更改的提交推送到存储库。限制为 200 个条目，每个条目最多 200 个字符。

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

还可以向此规则添加允许的例外。即使某个文件同时匹配受限路径，只要它匹配允许的例外规则，仍可被推送。

允许的异常使用 fnmatch 语法，并在保存规则集时进行验证。例如，**/gradle/wrapper/*.jar 允许在任何目录中使用 Gradle 包装器 JAR 文件。

规则集的可用规则

谁可以使用此功能？

在本文中

限制创建

限制更新