Pull requests can be merged in different ways. The best strategy depends on how your team wants the repository history to look and how much detail you want to preserve from the pull request branch.
| Strategy | Result | Choose when |
|---|---|---|
| Merge commit | Preserves every commit from the pull request branch and adds an explicit merge point. | Your team values complete history, or the individual commits are meaningful on their own. |
| Squash and merge | Combines all commits in the pull request into a single commit on the base branch. | A pull request represents one logical change, especially with many small fixup commits. |
| Rebase and merge | Adds each commit onto the base branch without a merge commit, for a linear history. | Your team wants a linear history and the commits are already organized clearly. |
Merge your commits
在拉取请求上单击默认的“合并拉取请求”选项**** 时，来自功能分支的所有提交都会在合并提交中添加到基础分支。 使用 --no-ff 选项合并拉取请求。
若要合并拉取请求，必须在存储库中拥有写入权限。
A merge commit preserves the full commit history from the pull request branch. This makes it easier to see every commit that led to the final change, including review fixes and intermediate work. It also creates an explicit merge point in the base branch history.
Choose this strategy when your team values complete history or when the individual commits in a pull request are meaningful on their own.
Squash and merge your commits
在拉取请求上选择“压缩并合并”**** 选项时，拉取请求的提交会压缩为单一提交。 不是从主题分支查看所有贡献者的个别提交，而是所有提交合并成一个提交并合并到默认分支。 使用快进选项合并包含已压缩提交的拉取请求。
若要压缩并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许压缩合并。
您可以使用压缩并合并在仓库中创建更简化的 Git 历史记录。 在功能分支上工作时，提交正在进行的工作会有帮助，但它们不一定必须留在 Git 历史记录中。 如果在合并到默认分支时将这些提交压缩为一个提交，更改将被整合，并生成清晰的 Git 历史记录。
Squashing turns all commits in the pull request into one commit on the base branch. This keeps the default branch history concise and can make it easier to scan later. The tradeoff is that intermediate commits from the pull request are not preserved as separate commits on the base branch.
Choose this strategy when a pull request represents one logical change, especially if the branch includes many small fixup commits.
Merge message for a squash merge
When you squash and merge, GitHub generates a default commit message that you can edit. The default message can include the pull request title, pull request description, or commit information, depending on repository settings and the number of commits in the pull request.
Maintainers and administrators can configure the default message for squashed commits. See 为拉取请求配置提交压缩.
Squashing and merging a long-running branch
Squash merging works best for short-lived branches. If you keep working on the same head branch after a squash merge, later pull requests can include commits that were already squashed into the base branch. This can make merge conflicts more likely and can force you to resolve the same conflicts more than once.
For long-running branches, consider using a merge commit or rebasing the branch before opening the next pull request.
Rebase and merge your commits
在拉取请求上选择“变基并合并”**** 选项时，来自主题分支（或头部分支）的所有提交都会单独添加到基分支，而无需合并提交。 这样，通过维护线性项目历史记录，变基和合并行为类似于快进合并。 但是，变基是通过在基分支上用新的提交重写提交历史记录来实现的。
GitHub 上的变基和合并行为与 git rebase 略有偏差。 GitHub 上的变基和合并始终会更新提交者信息并创建新的提交 SHA，而 GitHub 外部的 git rebase 在提交原型上发生变基时不改变提交者信息。 有关 git rebase 的详细信息，请参阅 Git 文档中的 git-revert。
若要变基并合并拉取请求，必须在存储库中具有写入权限，并且存储库必须允许变基合并。
有关 git rebase 的可视化表示形式，请参阅《Pro Git》一书中的“Git 分支 - 变基”章节。
Rebasing adds each commit from the pull request branch onto the base branch without creating a merge commit. This produces a linear history while preserving the individual commits from the pull request.
Choose this strategy when your team wants a linear history and the pull request commits are already organized clearly. If GitHub cannot safely rebase the pull request automatically, you can rebase locally, resolve conflicts, and push the updated branch. See Resolving a merge conflict using the command line and Merging a pull request.
Indirect merges
A pull request can be marked as merged if its head branch commits become reachable from the base branch outside that pull request. This can happen when the same commits are merged through another pull request or pushed directly to the default branch.
Indirect merges are uncommon, but they can affect automation and branch protection expectations. Pull requests merged indirectly are marked as merged even if branch protection rules on that pull request were not satisfied.