关于分支保护规则
您可以通过创建分支保护规则，在协作者将更改推送到仓库中的分支（包括将拉取请求合并到分支中）之前强制执行某些工作流程或要求。只有当仓库属于组织时，才能将参与者添加到绕过列表中。
默认情况下，每个分支保护规则都会禁用对匹配分支的强制推送，并防止删除匹配分支。您可以选择禁用这些限制并启用其他分支保护设置。
默认情况下，分支保护规则的限制不适用于对仓库具有管理员权限的人员或具有“绕过分支保护”权限的自定义角色。您也可以选择将限制应用于管理员和具有“绕过分支保护”权限的角色。有关更多信息，请参阅“管理组织的自定义仓库角色”。
您可以在仓库中为特定分支、所有分支或与您使用fnmatch语法指定的名称模式匹配的任何分支创建分支保护规则。例如，要保护包含单词release的任何分支，您可以为*release*创建分支规则。有关分支名称模式的更多信息，请参阅“管理分支保护规则”。
您可以配置拉取请求，以便在满足所有合并要求时自动合并。有关更多信息，请参阅“自动合并拉取请求”。
注意：一次只能应用一个分支保护规则，这意味着当多个版本的规则针对同一分支时，可能难以知道哪个规则将适用。有关分支保护规则替代方案的信息，请参阅“关于规则集”。
关于分支保护设置
对于每个分支保护规则，您可以选择启用或禁用以下设置。
有关如何设置分支保护的更多信息，请参阅“管理分支保护规则”。
合并前需要拉取请求审查
仓库管理员或具有“编辑仓库规则”权限的自定义角色可以要求所有拉取请求在有人将拉取请求合并到受保护的分支之前获得特定数量的批准审查。您可以要求仓库中具有写入权限的人员或指定代码所有者进行批准审查。
如果您启用强制审查，协作者只能通过拉取请求将更改推送到受保护的分支，该拉取请求需要获得具有写入权限的指定数量的审阅者的批准。
如果具有管理员权限的人员在审查中选择“请求更改”选项，则该人员必须批准拉取请求，然后才能合并拉取请求。如果请求更改拉取请求的审阅者不可用，则任何具有存储库写入权限的人员都可以驳回阻止审查。
即使所有必需的审阅者都批准了拉取请求，如果还有其他打开的拉取请求的头部分支指向具有待处理或拒绝审查的相同提交，协作者也不能合并拉取请求。具有写入权限的人员必须首先批准或驳回其他拉取请求上的阻止审查。
如果协作者尝试将具有待处理或拒绝审查的拉取请求合并到受保护的分支中，协作者将收到错误消息。
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes have been requested.
您可以选择在影响拉取请求中差异的提交被推送时驳回过时的拉取请求批准。GitHub 记录了拉取请求被批准时的差异状态。此状态表示审阅者批准的更改集。如果差异从此状态更改（例如，因为贡献者将新的更改推送到拉取请求分支或单击“更新分支”，或者因为相关拉取请求被合并到目标分支），则批准的审查将被驳回为过时，并且拉取请求无法合并，直到有人再次批准工作。有关基本分支的信息，请参阅“关于拉取请求”。
您可以选择将驳回拉取请求审查的能力限制为特定人员或团队。有关更多信息，请参阅“驳回拉取请求审查”。
您可以选择要求代码所有者进行审查。如果您选择这样做，任何影响代码所有者代码的拉取请求都必须获得该代码所有者的批准，然后才能将拉取请求合并到受保护的分支中。
您可以选择要求最新的可审查推送必须由除推送者以外的人员批准。这意味着至少一名其他授权审阅者已批准所有更改。例如，“最后审阅者”可以检查最新的更改集是否包含来自其他审阅的反馈，并且没有添加新的未审阅内容。
对于需要多次审阅的复杂拉取请求，要求除最后推送者以外的人员批准可以是一种折衷方案，避免了需要驳回所有过时的审阅：使用此选项，不会驳回“过时”的审阅，只要除最近进行更改的人员以外的人员批准，拉取请求就会保持批准状态。已经审阅过拉取请求的用户可以在最近推送后重新批准，以满足此要求。如果您担心拉取请求被“劫持”（未经批准的内容被添加到已批准的拉取请求中），那么驳回过时的审阅更安全。
注意
如果您选择**在推送新提交时驳回过时的拉取请求批准**和/或**要求批准最新的可审查推送**，则手动创建拉取请求的合并提交并将其直接推送到受保护的分支将失败，除非合并的内容与 GitHub 为拉取请求生成的合并完全匹配。
此外，使用这些设置，如果合并基础在提交审阅后引入了新的更改，则批准的审阅将被视为过时并被驳回。合并基础是主题分支和基础分支之间的最后一个共同祖先提交。如果合并基础发生更改，则拉取请求无法合并，直到有人再次批准工作。
合并前要求状态检查
必需的状态检查确保所有必需的 CI 测试在协作者可以对受保护的分支进行更改之前都已通过或跳过。必需的状态检查可以是检查或状态。有关更多信息，请参阅“关于状态检查”。
您可以使用提交状态 API 允许外部服务使用适当的状态标记提交。有关更多信息，请参阅“提交状态的 REST API 端点”。
启用必需的状态检查后，所有必需的状态检查都必须通过，然后协作者才能将更改合并到受保护的分支中。所有必需的状态检查通过后，所有提交必须要么推送到另一个分支然后合并，要么直接推送到受保护的分支。
任何拥有仓库写入权限的人员或集成都可以设置仓库中任何状态检查的状态，但在某些情况下，您可能只想接受来自特定 GitHub 应用的状态检查。当您添加必需状态检查时，可以选择最近将此检查设置为预期状态更新来源的应用。如果状态由任何其他人或集成设置，则不允许合并。如果您选择“任何来源”，您仍然可以手动验证每个状态的作者，这些作者列在合并框中。
您可以将必需状态检查设置为“宽松”或“严格”。您选择的必需状态检查类型决定了在合并之前是否要求您的分支与基分支保持最新。
| 必需状态检查类型 | 设置 | 合并要求 | 注意事项 |
|---|---|---|---|
| 严格 | 选中了**合并前要求分支保持最新**复选框。 | 合并前，分支**必须**与基分支保持最新。 | 这是必需状态检查的默认行为。可能需要更多构建，因为您需要在其他协作者更新目标分支后将头部分支更新到最新状态。 |
| 宽松 | **合并前要求分支保持最新**复选框**未**选中。 | 合并前，分支**不必**与基分支保持最新。 | 您将需要更少的构建，因为您不需要在其他协作者合并拉取请求后将头部分支更新到最新状态。如果您在合并分支后与基分支存在不兼容的更改，状态检查可能会失败。 |
| 已禁用 | **合并前要求状态检查通过**复选框**未**选中。 | 分支没有合并限制。 | 如果未启用必需状态检查，协作者可以随时合并分支，无论它是否与基分支保持最新。这会增加出现不兼容更改的可能性。 |
有关故障排除信息，请参阅“必需状态检查的故障排除”。
合并前要求解决对话
要求解决拉取请求上的所有评论，然后才能将其合并到受保护的分支。这确保在合并之前解决或确认所有评论。
要求签署提交
当您在分支上启用必需的提交签名时，贡献者和机器人只能将已签名和已验证的提交推送到该分支。有关更多信息，请参阅“关于提交签名验证”。
注意
- 如果您启用了警惕模式，这表示您的提交将始终被签名，GitHub 识别为“部分验证”的任何提交都允许在需要签署提交的分支上。有关警惕模式的更多信息，请参阅“显示所有提交的验证状态”。
- 如果协作者将未签名的提交推送到需要提交签名的分支，则协作者需要重新设置提交以包含已验证的签名，然后将重写的提交强制推送到分支。
如果提交已签名和验证，您始终可以将本地提交推送到分支。您还可以使用 GitHub 上的拉取请求将已签名和已验证的提交合并到分支中。但是，除非您是拉取请求的作者，否则您不能在 GitHub 上将拉取请求压缩并合并到分支中。您可以在本地压缩和合并拉取请求。有关更多信息，请参阅“在本地检出拉取请求”。
有关合并方法的更多信息，请参阅“关于 GitHub 上的合并方法”。
要求线性历史
强制执行线性提交历史记录可防止协作者将合并提交推送到分支。这意味着合并到受保护分支的任何拉取请求都必须使用压缩合并或变基合并。严格的线性提交历史记录可以帮助团队更轻松地撤消更改。有关合并方法的更多信息，请参阅“关于拉取请求合并”。
在您要求线性提交历史记录之前，您的仓库必须允许 squash 合并或 rebase 合并。有关更多信息，请参阅“配置拉取请求合并”。
要求合并队列
合并队列通过将拉取请求合并到繁忙的分支并确保分支不会因不兼容的更改而中断，从而帮助提高速度。
合并队列提供与要求分支在合并之前是最新的分支保护相同的好处，但不要求拉取请求作者更新其拉取请求分支并等待状态检查完成，然后再尝试合并。
使用合并队列在每天从许多不同用户合并大量拉取请求的分支上特别有用。
一旦拉取请求通过了所有必需的分支保护检查，具有仓库写入权限的用户就可以将拉取请求添加到队列中。合并队列将确保拉取请求的更改在应用于目标分支的最新版本以及队列中已有的任何拉取请求时，通过所有必需的状态检查。
合并队列可以使用 GitHub Actions 或您自己的 CI 提供程序在合并队列中的拉取请求上运行必需的检查。有关更多信息，请参阅“GitHub Actions 文档”。
一旦所有必需的 CI 检查通过，GitHub 将根据分支保护中配置的合并策略合并拉取请求。有关合并队列的更多信息，请参阅“管理合并队列”。
要求部署成功才能合并
您可以要求在分支可以合并之前，更改必须成功部署到特定环境。例如，您可以使用此规则来确保更改在更改合并到您的默认分支之前成功部署到暂存环境。
锁定分支
锁定分支将使分支只读，并确保无法对分支进行任何提交。锁定的分支也不能删除。
默认情况下，分叉的仓库不支持从其上游仓库同步。您可以启用 **允许分叉同步** 以从上游仓库拉取更改，同时防止对分叉分支的其他贡献。
不允许绕过上述设置
默认情况下，分支保护规则的限制不适用于对仓库具有管理员权限的人员，也不适用于在仓库中具有“绕过分支保护”权限的自定义角色。
您可以启用此设置，将限制也应用于管理员和具有“绕过分支保护”权限的角色。有关更多信息，请参阅“管理组织的自定义仓库角色”。
限制谁可以推送匹配的分支
您可以在由 GitHub Free 组织拥有的公共仓库以及由使用 GitHub Team 或 GitHub Enterprise Cloud 的组织拥有的所有仓库中启用分支限制。
启用分支限制后，只有被授予权限的用户、团队或应用才能推送到受保护的分支。您可以在受保护分支的设置中查看和编辑具有推送到受保护分支权限的用户、团队或应用。当需要状态检查时，即使所需检查失败，具有推送到受保护分支权限的人员、团队和应用仍然无法合并到该分支。具有推送到受保护分支权限的人员、团队和应用仍然需要在需要拉取请求时创建拉取请求。
您也可以选择将相同的限制应用于与规则匹配的分支的创建。例如，如果您创建了一条规则，只允许某个团队推送到包含“release”一词的任何分支，那么只有该团队的成员才能创建一个包含“release”一词的新分支。
您只能将推送访问权限授予受保护分支，或授予创建匹配分支的权限，授予拥有仓库写入权限的用户、团队或已安装的 GitHub 应用。拥有仓库管理员权限的人员和应用始终能够推送至受保护分支或创建匹配分支。
允许强制推送
默认情况下，GitHub 会阻止对所有受保护分支进行强制推送。当您为受保护分支启用强制推送时，您可以选择两个组之一来进行强制推送。
- 允许所有拥有至少仓库写入权限的用户（包括拥有管理员权限的用户）对分支进行强制推送。
- 仅允许特定人员或团队对分支进行强制推送。
如果有人对分支进行强制推送，强制推送可能意味着其他协作者在其工作基础上进行的提交将从分支的历史记录中删除。人员可能会遇到合并冲突或损坏的拉取请求。强制推送还可用于删除分支或将分支指向未在拉取请求中批准的提交。
启用强制推送不会覆盖任何其他分支保护规则。例如，如果分支需要线性提交历史记录，则您无法将合并提交强制推送至该分支。
允许删除
默认情况下，您无法删除受保护分支。当您启用受保护分支的删除功能时，任何拥有至少仓库写入权限的用户都可以删除该分支。
注意：如果分支被锁定，即使您有删除权限，也无法删除该分支。