注意
存储库策略目前为 公共预览版，可能会随时更改。 每个组织最多可以有 75 个策略和规则集，每个企业最多可以有 75 个策略和规则集。
若要控制仓库生命周期中的关键事件（例如谁可以创建或删除仓库），可以创建仓库策略。 仓库策略是一系列限制，可让你灵活控制影响的用户和目标仓库。
在仓库策略中，可以限制：
- 允许哪些可见性用于新仓库和可见性变更****。
- 谁可以创建仓库****。
- 谁可以删除仓库****。
- 谁可以从组织中转移仓库****。
- 人员如何命名仓库****。
提示
如果你是企业所有者，可以创建应用于多个组织的仓库策略****。 请参阅“治理人员如何在企业中使用仓库”。
示例
可以使用仓库策略执行以下操作：
- 确保所有新仓库都使用特定的命名约定，例如
kebab-case。 - 防止删除仓库（组织管理员除外）。
- 只允许在企业的“开放源代码”组织中创建公共仓库。
- 防止将公共仓库更改为专用仓库，以避免潜在的元数据丢失。
我如何确定目标仓库？
建议在使用仓库策略的同时使用自定义仓库属性****。 通过为仓库添加自定义属性，你就能在策略中灵活地确定这些目标仓库。
例如，可以添加一个属性来标记包含生产数据或其他敏感信息的仓库，然后阻止任何人公开这些仓库。
若要创建和设置自定义属性，请参阅 管理组织中存储库的自定义属性。
作为自定义属性的替代方法，可以从仓库列表中进行选择，或使用 fnmatch 语法来确定具有特定命名模式的目标仓库。
与其他策略的交互
一些可用的限制与你在组织或企业设置中的“Member privileges”页面设置的策略重复。
创建仓库策略不会覆盖现有的“成员特权”策略****。 相反，这些策略是相加的，因此适用的是最严格的策略版本。 这既适用于成员特权策略，也适用于人员在企业或组织级创建的其他仓库策略********。
与成员特权策略相比，仓库策略具有几个优点：
- 它们可以更灵活地确定目标组织和仓库。
- 它们可以让某些行为者选择绕过策略。
创建仓库策略
- 在 GitHub 的右上角，单击个人资料图片，然后单击“ Your organizations”****。
- 在组织旁边，单击“设置”。
- 在页面左侧的边栏中，单击“ Policies”****。
- 在“Policies”下，单击“Repository”****。
- 单击“新建策略”。
- 配置新策略，然后单击“Create”。**** 有关帮助，请参阅以下小节。
策略名称
用描述性的语言来表达策略的目的。 例如：Prevent public repos on production。
执法状况
如果不想在创建时执行策略，请设置为“Disabled”。 否则设置为“Active”。
允许列表
选择哪些角色可绕过此策略中的限制。****
目标
选择策略适用于组织中的哪些仓库。 可以选择所有仓库、选择现有仓库中的一个仓库，或者按名称或自定义属性为当前和将来的仓库创建动态规则。
如果按名称设置动态列表，将使用 fnmatch 语法添加一个或多个命名模式。
- 例如，字符串
*open-source将匹配名称以open-source结尾的任何仓库。 有关语法详细信息，请参阅“创建存储库的规则集”。 - （可选）可以阻止允许列表以外的任何人重命名所选仓库。 或者，可以在“Policies”部分中控制名称的格式。
策略
选择包含哪些限制。 当策略处于活动状态时，这些限制适用于所有目标仓库，但允许列表中的用户或团队可以绕过这些限制。
如果选择“限制名称”策略，则必须使用正则表达式语法来设置仓库名称必须匹配或不得匹配的模式****。 例如，执行 kebab-case 命名的模式看起来像 ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$。
- 模式支持 RE2 语法。 请参阅 Google 的语法指南。
- 若要验证表达式，请单击“Test pattern”，然后输入模式和测试值****。
委派绕过策略
注意
仓库策略委托绕过功能目前处于公共预览版阶段，后续可能发生变更。
仓库策略的委托绕过功能使你可以控制哪些人员可以绕过仓库删除和可见性更改的仓库策略。
通过委托绕过机制，仓库管理员必须提交请求才能更改仓库可见性或删除仓库。 该请求将被发送至指定的评审组，由评审人员决定是批准还是拒绝绕过仓库策略的请求。
如果绕过仓库策略的请求获得批准，所请求的更改将立即执行。 如果请求被拒绝，则不会执行请求的更改，但允许重新提交请求。
要配置委托绕过功能，企业所有者或组织所有者需先创建"绕过列表"。 绕过列表应包含特定角色和团队（如团队或仓库管理员），这些人员将负责监督绕过仓库策略的请求。 有关详细信息，请参阅“治理人员如何在企业中使用仓库”。
管理绕过请求
管理绕过推送规则的请求
注意
仓库策略委托绕过功能目前处于公共预览版阶段，后续可能发生变更。
可以在“策略”设置下的"Bypass Requests"页面中查看和管理所有特权绕过请求****。
可以按审批者（绕过列表的成员）、请求者（发出请求的参与者）、时间范围和状态来筛选请求。 将为请求分配以下状态：
| 状态 | 说明 |
|---|---|
Cancelled | 参与者已取消请求。 |
Completed | 请求已获批准，提交已推送至存储库。 |
Denied | 请求已审查并被拒绝。 |
Expired | 请求已过期。 请求的有效期为 7 天。 |
Open | 请求尚未审查，或者已批准，但提交尚未推送到存储库。 |
当参与者请求绕过特权来推送包含受限内容的提交时，绕过列表的成员都会收到一个电子邮件通知，其包含请求的链接。 然后，绕过列表的成员有 7 天的时间审查请求，并在请求过期之前批准或拒绝请求。
参与者会通过电子邮件通知该决定，必须采取所需的操作。 如果请求获得批准，则参与者可以将包含受限内容的提交推送到存储库。 如果请求被拒绝，则参与者必须从提交中移除受限内容后才能成功地将提交推送到存储库。