可以配置拉取请求合并选项以满足工作流需要，还可以配置用于管理 Git 历史记录的首选项。 有关详细信息，请参阅“配置拉取请求合并”。 您可以只对仓库启用所需的方法，以实施一种合并方法，如提交压缩或变基。
在拉取请求上单击默认的“合并拉取请求”选项**** 时，来自功能分支的所有提交都会在合并提交中添加到基础分支。 使用 --no-ff 选项合并拉取请求。
若要合并拉取请求，必须在存储库中拥有写入权限。
默认合并方法创建合并提交。 通过强制实施线性提交历史记录，可以防止任何人将合并提交推送到受保护分支。 有关详细信息，请参阅“关于受保护分支”。
压缩合并提交
在拉取请求上选择“压缩并合并”**** 选项时，拉取请求的提交会压缩为单一提交。 不是从主题分支查看所有贡献者的个别提交，而是所有提交合并成一个提交并合并到默认分支。 使用快进选项合并包含已压缩提交的拉取请求。
若要压缩并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许压缩合并。
您可以使用压缩并合并在仓库中创建更简化的 Git 历史记录。 在功能分支上工作时，提交正在进行的工作会有帮助，但它们不一定必须留在 Git 历史记录中。 如果在合并到默认分支时将这些提交压缩到一个提交中，您可以保留原来的更改并清除 Git 历史记录。
在启用压缩提交之前，请考虑以下缺点：
- 您会丢失关于最初何时执行了特定更改以及是谁进行了压缩提交的信息。
- 如果在压缩与合并后继续操作拉取请求的头部分支，然后在相同分支之间创建新的拉取请求，您先前被压缩与合并的提交将列于新的拉取请求中。 可能还有必须在每个连续的拉取请求中反复解决的冲突。 有关详细信息，请参阅“关于拉取请求合并”。
- 有些使用 "SHA" 或“哈希”ID 的 Git 命令可能更难使用，因为原始提交的 SHA ID 已经丢失。 例如，使用
git rerere可能不那么有效。
有关详细信息，请参阅“为拉取请求配置提交压缩”。
变基和合并提交
在拉取请求上选择“变基并合并”**** 选项时，来自主题分支（或头部分支）的所有提交都会单独添加到基分支，而无需合并提交。 这样，通过维护线性项目历史记录，变基和合并行为类似于快进合并。 但是，变基是通过在基分支上用新的提交重写提交历史记录来实现的。
GitHub Enterprise Server 上的变基和合并行为与 git rebase 略有偏差。 GitHub 上的变基和合并始终会更新提交者信息并创建新的提交 SHA，而 GitHub 外部的 git rebase 在提交原型上发生变基时不改变提交者信息。 有关 git rebase 的详细信息，请参阅 Git 文档中的 git-revert。
若要变基并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许变基合并。
有关 git rebase 的可视化表示形式，请参阅《Pro Git》一书中的“Git 分支 - 变基”章节。
在启用提交变基之前，请考虑以下缺点：
-
存储库贡献者可能必须在命令行上变基、解决所有冲突，并将其更改强制推送到拉取请求的主题分支（或远程头部分支），然后才可在 GitHub 上使用“变基和合并”选项****。 强制推送必须谨慎执行，以免贡献者覆盖别人在其工作基础上所做的工作。 若要详细了解何时在 GitHub 上禁用“变基和合并”选项，以及重新启用它的工作流，请参阅“关于拉取请求合并”****。
-
在拉取请求上使用“变基与合并”时，请务必注意，头分支中的提交将添加到基分支，无需提交签名验证。 使用此选项时，GitHub 会使用原始提交的数据和内容创建修改的提交。 这意味着 GitHub 未真正创建此提交，因此无法将其签名为通用系统用户。 GitHub 无权访问提交者的专用签名密钥，因此无法代表用户对提交进行签名。
解决方法是在本地进行变基和合并，然后将更改推送到拉取请求的基分支。
有关详细信息，请参阅“为拉取请求配置提交变基”。