Skip to main content

关于规则集

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

谁可以使用此功能

对存储库具有读取访问权限的任何人都可以查看存储库的规则集。 对存储库具有管理员访问权限的人员或者具有“编辑存储库规则”权限的自定义角色可以为存储库创建、编辑和删除规则集。

规则集在具有 GitHub Free 和 GitHub Free(适用于组织)的公共存储库中可用,在具有 GitHub Pro、GitHub Team 和 GitHub Enterprise Cloud 的公共和专用存储库中可用。 有关详细信息,请参阅“GitHub 的计划”。

关于规则集

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

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

创建规则集时,可以允许某些用户绕过规则集中的规则。 这可以是具有特定角色的用户(例如存储库管理员),也可以是特定团队或 GitHub Apps。

每个存储库规则集限制为 75 个。

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

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

此外,还可以将现有标记保护规则导入存储库规则集。 这样将实施你当前为存储库提供的相同标记保护。 有关详细信息,请参阅“配置标记保护规则”。

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

  • 与保护规则不同,可以同时应用多个规则集,因此可以确信,当有人与某个分支或标记交互时,存储库中适用于该分支或标记的所有规则都将得到评估。 有关详细信息,请参阅“关于规则分层”。
  • 规则集有状态,以便用户可以轻松管理存储库中处于活动状态的规则集,而无需删除规则集。
  • 对存储库具有读取访问权限的任何人都可以查看处于活动状态的存储库规则集。 这意味着开发人员可以了解因何触发了规则,或审核员可以检查存储库的安全约束,而无需存储库的管理员访问权限。

此外,对于有 GitHub Enterprise 计划的组织,可以使用规则集执行以下操作。

  • 在组织级别快速设置规则集,用于面向组织中的多个存储库。 有关详细信息,请参阅 GitHub Enterprise Cloud 文档中的“管理组织中存储库的规则集"
  • 创建更多规则来控制进入存储库的提交的元数据,例如提交消息和作者的电子邮件地址。 有关详细信息,请参阅 GitHub Enterprise Cloud 文档中的“规则集的可用规则"
  • 使用“评估”状态在激活规则集之前对其进行测试,并使用见解页面查看哪些用户操作受规则影响。 有关详细信息,请参阅 GitHub Enterprise Cloud 文档中的“管理存储库的规则集"

关于规则分层

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

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

  • 存储库的管理员已设置一个面向 my-feature 分支的规则集。 此规则集要求签名提交,并对拉取请求进行三次评审,然后才能合并拉取请求。
  • my-feature 分支的现有分支保护规则要求线性提交历史记录,并在合并拉取请求之前对拉取请求进行两次评审。

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