合并提交
在 你的 GitHub Enterprise Server 实例 的拉取请求上单击默认的“合并拉取请求”选项时，来自功能分支的所有提交都会在合并提交中添加到基础分支。 使用 --no-ff 选项合并拉取请求。
若要合并拉取请求，必须在存储库中拥有写入权限。
压缩和合并提交
对 你的 GitHub Enterprise Server 实例 上的拉取请求选择“压缩并合并”选项时，拉取请求的提交会压缩为单一提交。 不是从主题分支查看所有贡献者的个别提交，而是所有提交合并成一个提交并合并到默认分支。 使用快进选项合并包含已压缩提交的拉取请求。
若要压缩并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许压缩合并。
您可以使用压缩并合并在仓库中创建更简化的 Git 历史记录。 在功能分支上工作时，提交正在进行的工作会有帮助，但它们不一定必须留在 Git 历史记录中。 如果在合并到默认分支时将这些提交压缩到一个提交中，您可以保留原来的更改并清除 Git 历史记录。
合并压缩合并的消息
在压缩和合并时，GitHub 生成默认的提交消息，你可以对其进行编辑。 根据存储库的配置方式和拉取请求中的提交数（不包括合并提交），此消息可能包括拉取请求标题、拉取请求说明或有关提交的信息。
| 提交数 | 总结 | 说明 |
|---|---|---|
| 一个提交 | 单个提交的提交消息标题，后接拉取请求编号 | 单个提交的提交消息正文 |
| 多个提交 | 拉取请求标题，后接拉取请求编号 | 按日期顺序列出所有被压缩提交的提交消息 |
拥有存储库维护员或管理员权限的人员可以为所有已压缩提交配置其存储库的默认合并消息，以使用拉取请求标题、拉取请求标题和提交详细信息或拉取请求标题和说明。 有关详细信息，请参阅“为拉取请求配置提交压缩”。
压缩与合并长运行分支
如果计划在合并拉取请求后继续操作头部分支，建议不要压缩与合并拉取请求。
在创建拉取请求时，GitHub 会标识头部分支和基础分支上的最新提交：共同的提交原型。 在压缩与合并拉取请求时，GitHub 会在基础分支上创建提交，其中包含自提交原型以来对头部分支所做的所有更改。
由于此提交仅位于基础分支而不是头部分支上，因此两个分支的共同原型保持不变。 如果您继续使用头部分支，则在两个分支之间创建新的拉取请求，该拉取请求将包含自共同原型以来的所有提交，其中包括你在之前的拉取请求中压缩与合并的提交。 如果没有冲突，您可以安全地合并这些提交。 但是，此工作流会增大合并冲突的可能性。 如果您继续压缩与合并长运行头部分支的拉取请求，则必须反复解决相同的冲突。
对提交进行变基和合并
在 你的 GitHub Enterprise Server 实例 上的拉取请求中选择“变基并合并”选项时，来自主题分支（或头部分支）的所有提交都会单独添加到基分支，而无需合并提交。 这样，通过维护线性项目历史记录，变基和合并行为类似于快进合并。 但是，变基是通过在基分支上用新的提交重写提交历史记录来实现的。
GitHub Enterprise Server 上的变基和合并行为与 git rebase 略有偏差。 GitHub 上的变基和合并始终会更新提交者信息并创建新的提交 SHA，而 GitHub 外部的 git rebase 在提交原型上发生变基时不改变提交者信息。 有关 git rebase 的详细信息，请参阅 Git 文档中的 git-revert。
若要变基并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许变基合并。
有关 git rebase 的可视化表示形式，请参阅《Pro Git》一书中的“Git 分支 - 变基”章节。
在以下情况下，无法在 你的 GitHub Enterprise Server 实例 上自动变基与合并：
- 拉取请求有合并冲突。
- 将提交从基本分支变基为遇到冲突的头部分支。
- 变基提交被视为“不安全”，例如变基可行、不会发生冲突但会产生与合并不同的结果时。
如果你仍然要变基提交，但不能在 你的 GitHub Enterprise Server 实例 上自动变基与合并，则必须：
- 在命令行上以本地方式将主题分支（或头部分支）变基为基本分支
- 解决命令行上的任何合并冲突。
- 强制推送变基的命令到拉取请求的主题分支（或远端头部分支）。
在存储库中具有写入权限的任何人都可以使用 你的 GitHub Enterprise Server 实例 上的变基与合并按钮合并更改。
间接合并
如果拉取请求的头部分支直接或间接合并到外部的基础分支中，则可以自动合并。 换句话说，如果头部分支的顶端提交变得可从目标分支的顶端访问，就可以自动合并。 例如： 。
- 分支
main位于提交 C 处。 - 分支
feature已从main分支中分离出来，当前位于提交 D 处。此分支具有针对main的拉取请求。 - 分支
feature_2从feature分支中分离出来，现在位于提交 E 处。此分支同样具有针对main的拉取请求。
如果先合并拉取请求 E --> main，拉取请求 D --> main 将自动标记为已合并，因为来自 feature 的所有提交现在可从 main 访问。 将 feature_2 合并到 main 中，并通过命令行将 main 推送到服务器，会将两个拉取请求都标记为已合并。
仅当拉取请求头部分支中的提交直接推送到存储库的默认分支，或者当拉取请求头部分支中的提交存在于另一个拉取请求并使用“创建合并提交”选项合并到存储库的默认分支时，才会发生间接合并。
如果使用“Squash 和合并”或“变基和合并”选项合并包含其他拉取请求头部分支中存在的提交的拉取请求，则会在基础分支上创建新提交，并且不会自动合并其他拉取请求。
即使未满足分支保护规则，间接合并的拉取请求也会标记为 merged。