关于分支保护规则
您可以强制执行某些工作流或要求，然后协作者才能将更改推送到仓库中的分支（包括将拉取请求合并到分支中），方法是创建分支保护规则。仅当仓库属于组织时，才能将参与者添加到绕过列表中。
默认情况下，每个分支保护规则都会禁用对匹配分支的强制推送并阻止删除匹配分支。您可以选择禁用这些限制并启用其他分支保护设置。
默认情况下，分支保护规则的限制不适用于对仓库具有管理员权限的人员或具有“绕过分支保护”权限的自定义角色。您还可以选择将限制应用于管理员和具有“绕过分支保护”权限的角色。有关更多信息，请参阅“为组织管理自定义仓库角色”。
您可以为仓库中的特定分支、所有分支或与您使用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 上的合并方法”。
要求线性历史记录
强制执行线性提交历史记录可防止协作者将合并提交推送到分支。这意味着合并到受保护分支的任何拉取请求都必须使用压缩合并或变基合并。严格的线性提交历史记录可以帮助团队更轻松地回退更改。有关合并方法的更多信息，请参阅“关于拉取请求合并”。
在要求线性提交历史记录之前，您的存储库必须允许压缩合并或变基合并。有关更多信息，请参阅“配置拉取请求合并”。
要求合并队列
合并队列通过自动将拉取请求合并到繁忙的分支并确保分支永远不会因不兼容的更改而中断来帮助提高速度。
合并队列提供了与“**合并前要求分支是最新的**”分支保护相同的好处，但不要求拉取请求作者更新其拉取请求分支并在尝试合并之前等待状态检查完成。
在每天从许多不同用户合并大量拉取请求的分支上，使用合并队列尤其有用。
拉取请求通过所有必需的分支保护检查后，具有存储库写入访问权限的用户可以将拉取请求添加到队列中。合并队列将确保拉取请求的更改在应用于目标分支的最新版本以及队列中已有的任何拉取请求时通过所有必需的状态检查。
合并队列可以使用 GitHub Actions 或您自己的 CI 提供程序在合并队列中的拉取请求上运行必需的检查。有关更多信息，请参阅“GitHub Actions 文档”。
一旦所有必需的 CI 检查通过，GitHub 将根据分支保护中配置的合并策略合并拉取请求。有关合并队列的更多信息，请参阅“管理合并队列”。
合并前要求部署成功
您可以在合并分支之前要求将更改成功部署到特定环境。例如，您可以使用此规则来确保在将更改合并到默认分支之前，更改已成功部署到暂存环境。
锁定分支
锁定分支会使分支变为只读，并确保无法对分支进行任何提交。锁定的分支也不能被删除。
默认情况下，派生存储库不支持与其上游存储库同步。您可以启用“**允许派生同步**”以从上游存储库拉取更改，同时防止对派生分支的其他贡献。
不允许绕过上述设置
默认情况下，分支保护规则的限制不适用于对存储库具有管理员权限的人员或在存储库中具有“绕过分支保护”权限的自定义角色。
您可以启用此设置，以便也将限制应用于管理员和具有“绕过分支保护”权限的角色。有关更多信息，请参阅“管理组织的自定义存储库角色”。
限制谁可以推送到匹配的分支
您可以在 GitHub Free 组织拥有的公共存储库以及使用 GitHub Team 或 GitHub Enterprise Cloud 的组织拥有的所有存储库中启用分支限制。
启用分支限制后，只有被授予权限的用户、团队或应用才能推送到受保护的分支。您可以在受保护分支的设置中查看和编辑对受保护分支具有推送访问权限的用户、团队或应用。当需要状态检查时，即使必需的检查失败，对受保护分支具有推送权限的人员、团队和应用仍将被阻止合并到分支中。对受保护分支具有推送权限的人员、团队和应用在需要拉取请求时仍需要创建拉取请求。
或者，您可以将相同的限制应用于与规则匹配的分支的创建。例如，如果您创建一条规则，只允许某个特定团队推送包含单词release的任何分支，则只有该团队的成员才能创建包含单词release的新分支。
您只能对受保护分支授予推送访问权限，或授予创建匹配分支的权限，对象仅限于对存储库具有写入访问权限的用户、团队或已安装的 GitHub 应用。对存储库具有管理员权限的人员和应用始终能够推送到受保护分支或创建匹配的分支。
允许强制推送
默认情况下，GitHub 会阻止对所有受保护分支进行强制推送。当您对受保护分支启用强制推送时，您可以选择可以强制推送的两组用户之一
- 允许对存储库至少具有写入权限的所有人（包括具有管理员权限的人员）强制推送到分支。
- 仅允许特定人员或团队强制推送到分支。
如果有人强制推送到分支，则强制推送可能意味着其他协作者在其工作基础上进行的提交将从分支的历史记录中删除。人们可能会遇到合并冲突或损坏的拉取请求。强制推送也可用于删除分支或将分支指向未在拉取请求中批准的提交。
启用强制推送不会覆盖任何其他分支保护规则。例如，如果分支需要线性提交历史记录，则您不能强制推送到该分支的合并提交。
允许删除
默认情况下，您无法删除受保护的分支。当您启用受保护分支的删除时，任何对存储库至少具有写入权限的人员都可以删除该分支。
注意
如果分支已锁定，则即使您有权删除它，也无法删除该分支。