Wenn Du in einem Pull Request auf your GitHub Enterprise Server instance auf die standardmäßige Option Merge pull request (Pull Request zusammenführen) klickst, werden alle Commits aus dem Feature-Branch zum Basisbranch in einem Merge-Commit hinzugefügt. Der Pull Request wird mithilfe der Option --no-ff zusammengeführt.
Zum Zusammenführen von Pull Requests musst Du über Schreibberechtigungen im Repository verfügen.
Deine Pull-Request-Commits squashen und zusammenführen
Wenn Du die Option Squash and merge (Squash und Merge) in einer Abrufanfrage auf your GitHub Enterprise Server instance auswählst, werden die Commits der Abrufanfrage in einen einzelnen Commit gesquasht. 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 Requests mit gesquashten Commits werden mithilfe der Fast-Forward-Option zusammengeführt.
Zum Squashen und Mergen von Pull Requests musst Du im Repository über Schreibberechtigungen verfügen. Zudem muss im Repository Squash-Zusammenführung zulässig sein.
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 während dem Merge zum Standardbranch in einen Commit zusammenführst (squashen), kannst Du die ursprünglichen Änderungen in einem leeren Git-Verlauf beibehalten.
Merge message for a squash merge
When you squash and merge, GitHub generates a commit message which you can change if you want to. The message default depends on whether the pull request contains multiple commits or just one.
| Number of commits | Zusammenfassung | Beschreibung |
|---|---|---|
| One commit | The title of the commit message for the single commit, followed by the pull request number | The body text of the commit message for the single commit |
| More than one commit | The pull request title, followed by the pull request number | A list of the commit messages for all of the squashed commits, in date order |
Squashing and merging a long-running branch
If you plan to continue work on the head branch of a pull request after the pull request is merged, we recommend you don't squash and merge the pull request.
When you create a pull request, GitHub identifies the most recent commit that is on both the head branch and the base branch: the common ancestor commit. When you squash and merge the pull request, GitHub creates a commit on the base branch that contains all of the changes you made on the head branch since the common ancestor commit.
Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request. If there are no conflicts, you can safely merge these commits. However, this workflow makes merge conflicts more likely. If you continue to squash and merge pull requests for a long-running head branch, you will have to resolve the same conflicts repeatedly.
Rebase und Merge Deiner Pull-Request-Commits durchführen
Wenn Du die Option Rebase and merge (Rebase und Merge) für einen Pull Request auf your GitHub Enterprise Server instance auswählst, werden alle Commits vom Themen-Branch (oder Head-Branch) ohne einen Merge-Commit einzeln auf dem Basisbranch hinzugefügt. Pull Requests mit Rebased-Commits werden mithilfe der Fast-Forward-Option zusammengeführt.
Für das Rebasing und Mergen von Pull Requests musst Du im Repository über Schreibberechtigungen verfügen. Zudem muss das Repository Rebase-Merging zulassen.
Das Rebase- und Merge-Verhalten auf GitHub Enterprise Server weicht etwas von git rebase ab. Rebase und Merge auf GitHub aktualisiert jederzeit die Informationen zum Beitragenden und erstellt neue Commit-SHAs. Demgegenüber ändert git rebase außerhalb von GitHub nicht die Informationen zum Beitragenden, wenn das Rebasing zusätzlich zu einem Vorgänger-Commit erfolgt. Weitere Informationen zu git rebase findest Du im Kapitel zu „Git rebase“ im Pro Git-Buch.
Eine visuelle Darstellung von git rebase findest Du im Kapitel „Git-Branching - Rebasing“ im Pro Git-Buch.
In folgenden Fällen ist kein automatisches Rebasing und Zusammenführen auf your GitHub Enterprise Server instance möglich:
- Für den Pull Request liegen Mergekonflikte vor.
- Beim Rebasing der Commits vom Basis-Branch in den Head-Branch kommt es zu Konflikten.
- Das Rebasing der Commits gilt als „unsicher“, beispielsweise wenn ein Rebase ohne Mergekonflikte möglich ist, jedoch ein anderes Ergebnis liefern würde als ein Merge.
Wenn Sie trotzdem ein Rebasing der Commits durchführen möchten, aber kein automatischer Rebase auf your GitHub Enterprise Server instance möglich ist, müssen Sie folgendermaßen vorgehen:
- Führe ein Rebasing des Themen-Branches (oder Head-Branches) auf den Basis-Branch lokal in der Befehlszeile durch.
- Behebe Mergekonflikte in der Befehlszeile.
- Erzwinge den Push der Rebase-Commits an den Themen-Branch (oder Remote-Head-Branch) des Pull Requests.
Alle Benutzer mit Schreibberechtigungen im Repository können dann über die Rebase- und Merge-Schaltfläche auf your GitHub Enterprise Server instance die Änderungen zusammenführen .