关于规则集
规则集是应用于一个存储库的命名规则列表。 每个存储库最多可以有 75 个规则集。
创建规则集时,可以允许某些用户绕过规则集中的规则。 这可以是具有特定角色的用户(例如存储库管理员),也可以是特定团队或 GitHub Apps。 有关授予旁路权限的详细信息,请参阅“创建存储库的规则集”。
对于使用 GitHub Enterprise 计划的组织,可以在组织级别设置规则集,以针对组织中的多个存储库。 有关详细信息,请参阅“管理组织中存储库的规则集”(GitHub Enterprise Cloud 文档中)。
你可以使用规则集针对存储库中的分支或标签,或者阻止对存储库和存储库的整个分支网络的推送。
分支和标签规则集
可以创建规则集来控制用户如何与存储库中的选定分支和标记交互。 可以控制谁可以将提交推送到特定分支,或者谁可以删除或重命名标记。 例如,可以为存储库的 feature
分支设置一个规则集,针对除存储库管理员以外的所有用户要求签名提交和阻止强制推送。
对于创建的每个规则集,可以指定将规则集应用于存储库中的哪些分支或标记。 可以使用 fnmatch
语法定义一种模式,用于面向特定的分支和标记。 例如,可以使用 releases/**/*
模式来面向存储库中名称以字符串 releases/
开头的所有分支。 有关 fnmatch
语法的详细信息,请参阅“创建存储库的规则集”。
推送规则集
使用推送规则集,可以阻止对专用或内部存储库的推送,以及对此存储库整个分支网络的推送,具体取决于文件扩展名、文件路径长度、文件和文件夹路径以及文件大小。
推送规则不需要针对任何分支,因为它们会应用于对存储库的每条推送。
推送规则集允许你:
-
限制文件路径:阻止推送包含指定文件路径更改的提交。
可以为此使用
fnmatch
语法。 例如,针对test/demo/**/*
的限制可阻止对test/demo/
目录中的文件或文件夹进行任何推送。 针对test/docs/pushrules.md
的限制可阻止对pushrules.md
目录中test/docs/
文件的专门推送。 有关详细信息,请参阅“创建存储库的规则集”。 -
限制文件路径长度:阻止推送包含超过指定字符限制的文件路径的提交。
-
限制文件扩展名:阻止推送包含具有指定文件扩展名的文件的提交。
-
限制文件大小:阻止推送超过指定文件大小限制的提交。
关于向已创建分支的存储库推送规则集
推送规则适用于存储库的整个分支网络,以确保存储库的每个入口点均受到保护。 例如,如果将已启用推送规则集的存储库创建为分支,则相同的推送规则集也适用于已创建分支的存储库。
对于已创建分支的存储库,只有对推送规则具有旁路权限的人员是根存储库中具有旁路权限的人员。
关于规则集和受保护的分支
规则集与存储库中的任何分支保护规则一起产生作用。 可在规则集中定义的许多规则都与保护规则类似,使用规则集时无需重写任何现有保护规则。
与分支保护规则相比,规则集具有以下优势。
- 与保护规则不同,可以同时应用多个规则集,因此可以确信,当有人与某个分支交互时,存储库中适用于该分支的所有规则都将得到评估。 请参阅关于规则分层。
- 规则集有状态,以便用户可以轻松管理存储库中处于活动状态的规则集,而无需删除规则集。
- 对存储库具有读取访问权限的任何人都可以查看处于活动状态的存储库规则集。 这意味着开发人员可以了解因何触发了规则,或审核员可以检查存储库的安全约束,而无需存储库的管理员访问权限。
- 你可以创建更多规则来控制进入存储库的提交的元数据,例如提交消息和作者的电子邮件地址。 请参阅“规则集的可用规则”(GitHub Enterprise Cloud 文档中)
使用规则集强制实施状态
创建或编辑规则集时,可以使用强制状态来配置规则集的强制实施方式。
可以为规则集选择以下任何强制状态。
- 活动:规则集创建后便会强制实施。****
- 已禁用:不会强制实施规则集。****
关于规则分层
规则集没有优先级。 如果多个规则集适用于存储库中的同一分支或标记,会将每个规则集中的规则进行聚合。 如果在聚合的规则集中同一规则以不同方式定义,则会应用该规则的最严格版本。 除了相互分层外,规则集还与面向同一分支或标记的保护规则进行分层。
例如,对于 octo-org/octo-repo
存储库的 my-feature
分支,请考虑以下情况。
- 存储库的管理员已设置一个面向
my-feature
分支的规则集。 此规则集要求签名提交,并对拉取请求进行三次评审,然后才能合并拉取请求。 my-feature
分支的现有分支保护规则要求线性提交历史记录,并在合并拉取请求之前对拉取请求进行两次评审。
会将每个源中的规则进行聚合,并应用所有规则。 如果存在同一规则的多个不同版本,结果将是应用该规则的最严格版本。 因此,my-feature
分支需要签名提交和线性提交历史记录,且面向该分支的拉取请求需要三次评审才能合并。