拉取请求的最后一步是将已完成的工作合并到部署分支中。 这通常意味着将更改合并到发布或主分支中。 在发生这种情况之前，需要确认更改是否满足项目的要求。
验证部署前检查
在合并之前，你需要确认该更改可以安全部署。 状态检查 显示提交是否符合为存储库设置的条件，例如持续集成生成、测试、代码扫描或部署检查。 它们可帮助你和审阅者了解拉取请求是否已准备好合并。
存储库通常需要某些条件才能合并拉取请求，包括：
- 必须通过的必需状态检查，例如部署管道运行的应用程序运行状况和就绪情况检查。
- 必需的审查或代码所有者批准。
- 必须解决合并冲突。
受保护的分支强制实施这些要求，以便部署分支保持稳定。
并非所有检查都是相同的。 由 GitHub Actions 等产品创建的详细检查可以报告详细的日志和批注，而更简单的提交状态则可以由多种已连接的系统发布。 理解这些内容有助于你判断为什么拉取请求已准备就绪或尚未准备就绪。
将代码合并到发布或主分支中
满足相关要求后，您可以合并拉取请求，将其中的提交合并到基础分支中。 您还可以设置自动合并，以便拉取请求在满足其要求后立即合并。 拉取请求提供了不同的合并策略，具体取决于你希望仓库历史记录呈现的方式：
- 合并提交 会保留请求分支中的每个提交，并添加显式合并点。
- 压缩并合并会将所有提交合并为一个提交，从而使提交历史更简洁。
- 重新建立和合并 会将每个提交添加到线性历史记录的基分支中，而无需进行合并提交。
最佳策略取决于团队想要保留多少细节。
大规模落实要求
合并变得更繁忙时，团队会添加控件，以确保合并安全且可预测：
- 规则集和分支保护可以要求分支在合并前处于最新状态、提交已签名、具有线性历史，或通过特定的状态检查。
- 合并队列可让受保护的高流量分支在不被破坏的情况下接受多个拉取请求。 它会基于基础分支的最新版本对其逐个进行测试，并在通过检查后按顺序将其合并。 当分支使用合并队列时，可用的合并选项不同于标准合并。
注意
拉取请求合并队列在组织拥有的任何公共存储库中均处于可用状态，或在使用 GitHub Enterprise Cloud 的组织拥有的专用存储库中处于可用状态。 请参阅“GitHub的计划”。
将合并与部署关联起来
合并通常是触发代码发布的因素。 GitHub Actions 当拉取请求合并到发布或主分支时，可以运行部署工作流。 部署环境 增加了另一层预部署安全性：可以在部署继续之前要求特定的审阅者、等待计时器或分支限制，这些限制与其他检查一起浮出水面。
合并后恢复
即使已经实施了检查措施，某些合并仍需要撤销。 您可以还原已合并的拉取请求，以创建一个新的拉取请求来撤销这些更改。 请注意，在极少数情况下，如果拉取请求中的提交通过其他途径进入基础分支，该拉取请求可能会被标记为间接地已合并。 这可以绕过该特定拉取请求的保护。 请参阅 还原拉取请求 和 合并拉取请求。
关闭不会被合并的拉取请求
并非每个拉取请求都应合并。 如果不再需要更改或被其他工作取代，则可以关闭拉取请求而不将其合并。 关闭会保留讨论和历史记录以供参考，同时表明更改不会向前推进。
合并或关闭拉取请求后，通常不再需要其头分支。 删除未使用的分支可以更轻松地导航存储库。