Skip to main content

此版本的 GitHub Enterprise Server 将于以下日期停止服务 2026-06-02. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

关于规则集

规则集有助于控制用户如何与存储库中的分支和标记交互。

谁可以使用此功能?

对存储库具有读取访问权限的任何人都可以查看存储库的规则集。 对仓库具有管理员访问权限的人员或者具有“编辑仓库规则”权限的自定义角色可以为仓库创建、编辑和删除规则集并查看规则集见解。 有关详细信息,请参阅“关于自定义存储库角色”。

规则集在具有 GitHub Free 和 GitHub Free(适用于组织)的公共存储库中可用,在具有 GitHub Pro、GitHub Team 和 GitHub Enterprise Cloud 的公共和专用存储库中可用。

关于规则集

规则集是适用于存储库或组织中多个存储库的规则的命名列表,适用于客户 GitHub Team 和 GitHub Enterprise 计划。 可以为每个存储库配置最多 75 个规则集,以及 75 个组织范围的规则集。

创建规则集时,可以允许某些用户绕过规则集中的规则。 这可以是具有特定角色的用户,例如存储库管理员,也可以是特定的团队或 GitHub Apps。 有关授予旁路权限的详细信息,请参阅“创建存储库的规则集”。

借助推送规则集委派绕过功能,可以控制谁可以绕过推送保护以及应允许哪些被阻止的推送。

启用委派绕过后,存储库的参与者在推送包含受限内容的提交时必须请求“绕过特权”。 请求将发送到指定的审阅者组,他们批准或拒绝绕过推送规则的请求。

如果绕过推送规则的请求获得批准,则参与者可以推送包含受限内容的提交。 如果请求被拒绝,则参与者必须首先从包含受限内容的提交中移除相关内容,然后才能再次推送。

若要配置委派绕过,组织所有者或存储库管理员首先会创建“绕过列表”。 绕过列表包括特定角色和团队,例如安全团队或存储库管理员,他们负责监督绕过推送保护的请求。 有关详细信息,请参阅 管理您组织存储库的规则集关于规则集

分支和标签规则集

可以创建规则集来控制用户如何与存储库中的选定分支和标记交互。 可以控制哪些人员可以将提交推送到特定分支 以及如何设置提交的格式,或者谁可以删除或重命名标记。 例如,可以为存储库的 feature 分支设置一个规则集,针对除存储库管理员以外的所有用户要求签名提交和阻止强制推送。

对于你创建的每个规则集,可以指定存储库中的哪些分支或标记,或者指定组织中的哪些存储库, 规则集适用于这些规则集。 可以使用 fnmatch 语法来定义面向特定 分支、标记和存储库的模式。 例如,可以使用 releases/**/* 模式来面向存储库中名称以字符串 releases/ 开头的所有分支。 有关 fnmatch 语法的详细信息,请参阅“创建存储库的规则集”。

关于规则集和受保护的分支

规则集与存储库中的任何分支保护规则共同产生作用。 可在规则集中定义的许多规则都与保护规则类似,使用规则集时无需重写任何现有保护规则。

与分支保护规则相比,规则集具有以下优势。

  • 与保护规则不同,多个规则集可以同时应用,因此可以确信当有人与该分支交互时,将评估存储库中面向分支的每个规则。 请参阅关于规则分层
  • 规则集有状态,以便用户可以轻松管理存储库中处于活动状态的规则集,而无需删除规则集。
  • 对存储库具有读取访问权限的任何人都可以查看处于活动状态的存储库规则集。 这意味着开发人员可以了解因何触发了规则,或审核员可以检查存储库的安全约束,而无需存储库的管理员访问权限。
  • 你可以创建更多规则来控制进入存储库的提交的元数据,例如提交消息和作者的电子邮件地址。 请参阅 规则集的可用规则 在GitHub Enterprise Cloud文档中。

使用规则集强制实施状态

创建或编辑规则集时,可以使用强制状态来配置规则集的强制实施方式。

可以为规则集选择以下任何强制状态。

  • Active:规则集创建后便会强制实施。****
  • Evaluate:不会强制执行规则集,但你能够在“Rule Insights”页上监控哪些操作会或不会违反规则。****
  • Disabled:不会强制实施或评估规则集。****

使用“评估”模式是在不强制执行规则集的情况下测试规则集的绝佳选择。 可以使用“规则见解”页查看贡献是否违反了规则。

关于规则分层

规则集没有优先级。 如果多个规则集适用于存储库中的同一分支或标记,会将每个规则集中的规则进行聚合。 如果在聚合的规则集中同一规则以不同方式定义,则会应用该规则的最严格版本。 除了相互叠加外,规则集还与针对同一分支或标签的保护规则进行分层。

例如,对于 my-feature 存储库的 octo-org/octo-repo 分支,请考虑以下情况。

  • 存储库的管理员已设置一个面向 my-feature 分支的规则集。 此规则集要求签名提交,并对拉取请求进行三次评审,然后才能合并拉取请求。
  • 现有的 my-feature 分支保护规则要求提交历史记录为线性,并且在拉取请求合并之前必须经过两次评审。
  • octo-org 组织的管理员还设置了面向 my-feature 存储库 octo-repo 分支的规则集。 规则集会阻止强制推送,并要求对拉取请求进行一次评审,然后才能合并。

会将每个源中的规则进行聚合,并应用所有规则。 如果存在同一规则的多个不同版本,结果将是应用该规则的最严格版本。 因此, my-feature 分支需要签名的提交和线性提交历史记录、强制推送被阻止,并且针对分支的拉取请求需要三个评审才能合并。