您可以配置拉取请求的合并选项，以满足工作流需求和管理 Git 历史的偏好。更多信息请参阅 配置拉取请求合并。通过仅为仓库启用所需的方式，您还可以强制只使用一种合并方法，例如压缩提交或变基合并。
注意
使用合并队列时，您将无法自行选择合并方式，因为该方式由队列控制。有关合并队列的更多信息，请参阅 管理合并队列。
在仓库上设置的合并方式如果与合并规则冲突，将阻止合并。例如，若仓库不允许变基合并，而合并规则只在某分支上允许变基，则该合并将无法进行。更多信息请参阅 规则集可用规则。
当您点击拉取请求中的默认 Merge pull request 选项时，所有来自功能分支的提交都会以合并提交的形式添加到基准分支。该拉取请求使用 --no-ff 选项 进行合并。
要合并拉取请求，您必须在仓库中拥有 写入权限。
默认的合并方式会创建一个合并提交。通过强制线性提交历史，您可以防止任何人向受保护分支推送合并提交。更多信息请参阅 受保护分支概述。
压缩合并提交
当您在拉取请求上选择 Squash and merge 选项时，拉取请求的提交会被压缩成一个单一提交。这样，您将不再看到来自主题分支的贡献者的每个单独提交，而是将所有提交合并为一个提交后再合并到默认分支。压缩提交的拉取请求使用 快进合并 方式进行合并。
要压缩并合并拉取请求，您必须在仓库中拥有 写入权限，且仓库必须 允许压缩合并。
使用压缩合并可以让仓库的 Git 历史更加简洁。 在功能分支上进行的开发过程提交在开发期间非常有用，但它们未必需要保留在 Git 历史中。 当您在合并到默认分支时将这些提交压缩为一次提交，变更会被汇总，从而形成清晰的 Git 历史。
在启用压缩提交之前，请考虑以下缺点
- 您将失去关于特定变更最初何时完成以及是谁编写这些压缩提交的详细信息。
- 如果在压缩并合并后继续在拉取请求的源分支上工作，然后在相同的分支之间创建新的拉取请求，先前已压缩并合并的提交将会出现在新的拉取请求中。您可能还会遇到需要在每个后续拉取请求中反复解决的冲突。更多信息请参阅 关于拉取请求合并。
- 某些使用 “SHA” 或 “哈希” ID 的 Git 命令可能会更难使用，因为原始提交的 SHA ID 已经丢失。例如，使用
git rerere可能就不太奏效。
更多信息请参阅 配置拉取请求的提交压缩。
变基并合并提交
当您在拉取请求上选择 Rebase and merge 选项时，主题分支（或源分支）的所有提交会逐个添加到基准分支上，且不会产生合并提交。这样，变基合并的行为类似于 快进合并，能够保持线性的项目历史。不过，变基是通过在基准分支上重新写入提交历史来实现的。
GitHub 上的变基合并与 git rebase 稍有不同。GitHub 上的变基合并始终会更新提交者信息并创建全新的提交 SHA，而在 GitHub 之外使用 git rebase 时，如果变基发生在某个祖先提交之上，提交者信息通常保持不变。有关 git rebase 的更多信息，请参阅 Git 文档中的 git-rebase。
要变基并合并拉取请求，您必须在仓库中拥有 写入权限，且仓库必须 允许变基合并。
有关 git rebase 的可视化说明，请参阅 《Pro Git》一书中的 “Git Branching - Rebasing” 章节。
在启用提交变基之前，请考虑以下缺点
-
仓库贡献者可能需要在命令行上执行变基、解决冲突，然后强制推送他们对拉取请求主题分支（或远程源分支）的更改，才能使用 GitHub 上的 rebase and merge 选项。强制推送必须谨慎操作，以免覆盖其他人已经基于该分支进行的工作。若想了解在何种情况下 GitHub 会禁用 Rebase and merge 选项以及如何重新启用它的工作流，请参阅 关于拉取请求合并。
-
在拉取请求上使用 Rebase and Merge 选项时，需要注意，源分支的提交会被添加到基准分支中，而不会进行提交签名验证。使用此选项时，GitHub 会基于原始提交的数据和内容创建一个修改后的提交。这意味着该提交并非真正由 GitHub 创建，因而无法以通用系统用户的身份签名。GitHub 并不拥有提交者的私有签名密钥，无法代表用户对提交进行签名。
一种变通方法是先在本地执行变基并合并，然后再将更改推送到拉取请求的基准分支。
更多信息请参阅 配置拉取请求的提交变基。