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
Wenn Sie in einem Pull Request auf die standardmäßige Option Pull Request mergen klicken, werden alle Commits aus dem Featurebranch dem Basisbranch in einem Mergecommit hinzugefügt. Der Pull Request wird über die --no-ff-Option gemergt.
Um Pull Requests mergen zu können, musst du über Schreibberechtigungen im Repository verfügen.
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
Wenn Sie die Option Squash und Merge in einem Pull Request auswählen, werden die Commits des Pull Requests in einem einzigen Commit zusammengefasst. Anstatt dass alle einzelnen Commits eines Mitarbeiters aus einem Themen-Branch angezeigt werden, werden die Commits in einem Commit kombiniert und in den Standardbranch zusammengeführt. Pull Request mit so zusammengefassten Commits werden mithilfe der Vorlaufoption gemergt.
Zum Squashmergen von Pull Requests musst du über Schreibberechtigungen im Repository verfügen, und das Repository muss das Squashmergen zulassen.
Mittels Squash und Merge kannst du einen optimierteren Git-Verlauf in deinem Repository erstellen. In Arbeit befindliche Commits sind hilfreich, wenn du auf einem Feature-Branch arbeitest, sie müssen aber nicht unbedingt im Git-Verlauf beibehalten werden. Wenn du diese Commits beim Mergen mit dem Standardbranch squashst, werden die Änderungen konsolidiert, was zu einem übersichtlichen Git-Verlauf führt.
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 Commit-Squashing für Pull-Requests konfigurieren.
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
Wenn Sie bei einem Pull Request die Option Rebase and merge auswählen, werden alle Commits aus dem Topic-Branch (oder Head-Branch) einzeln auf den Basis-Branch angewendet, ohne einen Merge-Commit zu erstellen. Auf diese Weise ähnelt das Verhalten von Rebase und Merge einem Fast-Forward-Merge, da ein linearer Projektverlauf beibehalten wird. Beim Rebase wird dies jedoch erreicht, indem die Commit-Historie des Basis-Branches durch neue Commits umgeschrieben wird.
Das Rebase- und Merge-Verhalten auf GitHub weicht außerhalb von GitHub geringfügig von git rebase ab. Rebase und zusammenführen auf GitHub:
- Aktualisiert immer die Committer-Informationen und erstellt neue Commit-SHAs, während
git rebasedie Committer-Informationen nicht ändert, wenn das Rebase auf einem Vorfahren-Commit erfolgt. - Verwirft Commits, die von Anfang an leer waren, wie z. B. solche, die mit
git commit --allow-emptyerstellt wurden, währendgit rebaseursprünglich leere Commits standardmäßig beibehält.
Weitere Informationen zu git rebase finden Sie unter git-rebase in der Git-Dokumentation.
Zum Ausführen von „Rebase und Merge“ für Pull Requests musst du im Repository über Schreibberechtigungen verfügen, und das Repository muss Rebase und Merge zulassen.
Eine visuelle Darstellung von git rebase finden Sie im Kapitel „Git Branching – Rebasing“ aus dem Pro Git-Buch.
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.
