关于 GitHub 上的合并方法

您可以在 GitHub.com 上配置拉取请求合并选项，以满足您管理 Git 历史记录的工作流程需求和偏好。有关更多信息，请参阅“配置拉取请求合并”。您可以通过仅为您的仓库启用所需的方法来强制执行一种合并方法类型，例如提交压缩或变基。

当您在 GitHub.com 上的拉取请求中点击默认的合并拉取请求选项时，功能分支中的所有提交都将通过合并提交添加到基分支中。拉取请求将使用--no-ff 选项进行合并。

要合并拉取请求，您必须在存储库中具有写入权限。

默认的合并方法会创建一个合并提交。您可以通过强制执行线性提交历史记录来阻止任何人将合并提交推送到受保护的分支。有关更多信息，请参阅“关于受保护的分支”。

压缩您的合并提交

当您在 GitHub.com 上的拉取请求中选择压缩并合并选项时，拉取请求的提交将被压缩成单个提交。您将不会看到贡献者从主题分支中提交的所有个人提交，而是将这些提交合并成一个提交并合并到默认分支中。使用压缩提交合并的拉取请求将使用快进选项进行合并。

要压缩并合并拉取请求，您必须在存储库中具有写入权限，并且存储库必须允许压缩合并。

您可以使用 squash and merge 在您的仓库中创建更简洁的 Git 历史记录。工作进行中的提交在处理功能分支时很有用，但它们并不一定需要保留在 Git 历史记录中。如果您在合并到默认分支时将这些提交压缩成一个提交，您可以保留原始更改并获得清晰的 Git 历史记录。

在启用压缩提交之前，请考虑以下缺点

• 您将丢失有关最初进行特定更改的时间以及谁编写了压缩提交的信息。
• 如果您在压缩和合并后继续处理拉取请求的头部分支，然后在相同分支之间创建新的拉取请求，您之前压缩和合并的提交将列在新拉取请求中。您可能还会遇到必须在每个后续拉取请求中重复解决的冲突。有关更多信息，请参阅“关于拉取请求合并”。
• 某些使用“SHA”或“哈希”ID 的 Git 命令可能更难使用，因为原始提交的 SHA ID 已丢失。例如，使用 git rerere 可能不会像以前那样有效。

有关更多信息，请参阅“配置拉取请求的提交压缩”。

变基和合并您的提交

当您在 GitHub.com 上的拉取请求中选择 **变基和合并** 选项时，主题分支（或头部分支）中的所有提交将单独添加到基础分支，而不会产生合并提交。这样，变基和合并行为类似于 快进合并，通过维护线性项目历史记录来实现。但是，变基通过在基础分支上用新提交重写提交历史记录来实现这一点。

GitHub 上的变基和合并行为与 git rebase 略有不同。GitHub 上的变基和合并将始终更新提交者信息并创建新的提交 SHA，而 GitHub 之外的 git rebase 在变基发生在祖先提交之上时不会更改提交者信息。有关 git rebase 的更多信息，请参阅 Git 文档中的 git-rebase。

要变基和合并拉取请求，您必须在仓库中具有 写入权限，并且仓库必须 允许变基合并。

有关 git rebase 的可视化表示，请参阅 Pro Git 书籍中的“Git 分支 - 变基”章节。

在启用提交变基之前，请考虑以下缺点

• 存储库贡献者可能需要在命令行上进行变基，解决任何冲突，并将他们的更改强制推送到拉取请求的主题分支（或远程头部分支），然后才能在 GitHub.com 上使用 **变基并合并** 选项。强制推送必须谨慎进行，以确保贡献者不会覆盖其他人基于其工作所做的工作。要详细了解何时在 GitHub.com 上禁用 **变基并合并** 选项以及重新启用它的工作流程，请参阅 "关于拉取请求合并。"。

• 在拉取请求中使用 **变基并合并** 选项时，请务必注意，头部分支中的提交将添加到基础分支中，而不会进行提交签名验证。使用此选项时，GitHub 会使用原始提交的数据和内容创建修改后的提交。这意味着 GitHub 并没有真正创建此提交，因此无法将其签署为通用系统用户。GitHub 无法访问提交者的私有签名密钥，因此无法代表用户签署提交。

  解决此问题的办法是在本地进行变基并合并，然后将更改推送到拉取请求的基础分支。

有关更多信息，请参阅 "为拉取请求配置提交变基。"。