您可以配置拉取请求合并选项，以满足您管理 Git 历史记录的工作流需求和偏好。有关更多信息，请参阅“配置拉取请求合并”。您可以通过仅为您的仓库启用所需的方法来强制执行一种合并方法，例如提交压缩或变基。
注意
使用合并队列时，您将不再可以选择合并方法，因为这是由队列控制的。有关合并队列的更多信息，请参阅“管理合并队列”。
当您在拉取请求上单击默认的**合并拉取请求**选项时，功能分支中的所有提交都将以合并提交的形式添加到基础分支中。拉取请求使用--no-ff选项进行合并。
要合并拉取请求，您必须在仓库中拥有写入权限。
默认的合并方法会创建合并提交。您可以通过强制执行线性提交历史记录来阻止任何人将合并提交推送到受保护的分支。有关更多信息，请参阅“关于受保护的分支”。
压缩合并提交
当您在拉取请求上选择**压缩并合并**选项时，拉取请求的提交将被压缩成单个提交。您不会看到主题分支中所有贡献者的单个提交，而是将这些提交合并到一个提交中并合并到默认分支中。使用压缩提交的拉取请求使用快进选项进行合并。
要压缩并合并拉取请求，您必须在仓库中拥有写入权限，并且仓库必须允许压缩合并。
您可以使用压缩和合并在仓库中创建更简化的 Git 历史记录。在处理功能分支时，工作进度提交非常有用，但它们并非一定需要保留在 Git 历史记录中。如果您在合并到默认分支时将这些提交压缩到一个提交中，则可以保留原始更改并保持清晰的 Git 历史记录。
在启用压缩提交之前，请考虑以下缺点
- 您将丢失有关最初进行特定更改的时间以及谁编写了压缩提交的信息。
- 如果您在压缩和合并后继续处理拉取请求的头分支，然后在相同分支之间创建新的拉取请求，则之前压缩和合并的提交将列在新拉取请求中。您可能还会遇到必须在每个后续拉取请求中重复解决的冲突。有关更多信息，请参阅“关于拉取请求合并”。
- 某些使用“SHA”或“哈希”ID 的 Git 命令可能更难使用，因为原始提交的 SHA ID 已丢失。例如，使用
git rerere可能不会那么有效。
有关更多信息，请参阅“配置拉取请求的提交压缩”。
变基和合并提交
当您在拉取请求上选择**变基并合并**选项时，主题分支（或头分支）中的所有提交都将单独添加到基础分支中，而不会创建合并提交。这样，变基和合并行为类似于快进合并，因为它维护了线性的项目历史记录。但是，变基通过使用新提交重写基础分支上的提交历史记录来实现此目的。
GitHub 上的变基和合并行为与git rebase略有不同。GitHub 上的变基和合并将始终更新提交者信息并创建新的提交 SHA，而 GitHub 之外的git rebase在变基发生在祖先提交之上时不会更改提交者信息。有关git rebase的更多信息，请参阅 Git 文档中的git-rebase。
要变基并合并拉取请求，您必须在仓库中拥有写入权限，并且仓库必须允许变基合并。
有关git rebase的直观表示，请参阅《Pro Git》一书中的“Git 分支 - 变基”章节。
在启用提交变基之前，请考虑以下缺点
-
仓库贡献者可能必须在命令行上进行变基，解决任何冲突，并强制推送到拉取请求的主题分支（或远程头分支），然后才能在 GitHub 上使用**变基并合并**选项。必须谨慎执行强制推送，以确保贡献者不会覆盖其他人已在其工作基础上进行的工作。要了解有关 GitHub 上何时禁用**变基并合并**选项以及重新启用它的工作流的更多信息，请参阅“关于拉取请求合并”。
-
在拉取请求上使用**变基并合并**选项时，请务必注意，头分支中的提交将添加到基础分支中，而不会进行提交签名验证。当您使用此选项时，GitHub 会使用原始提交的数据和内容创建修改后的提交。这意味着 GitHub 并没有真正创建此提交，因此无法将其签署为通用系统用户。GitHub 无法访问提交者的私有签名密钥，因此无法代表用户签署提交。
解决此问题的办法是在本地进行变基和合并，然后将更改推送到拉取请求的基础分支。
有关更多信息，请参阅“配置拉取请求的提交变基”。