Informationen zum Zusammenführen von Pull Requests

Mergen von Commits

Wenn du in einem Pull Request auf Ihre GitHub Enterprise Server-Instance auf die standardmäßige Option Pull Request mergen klickst, 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.

Diagramm des Standardablaufs für Merge- und Commitvorgänge, bei dem Commits aus einem Featurebranch und ein zusätzlicher Mergecommit zu main hinzugefügt werden

Squashen und Mergen von Commits

Wenn du die Option Squash und Merge in einem Pull Request auf Ihre GitHub Enterprise Server-Instance auswählst, 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.

Diagramm des Commit-Squashings, bei dem mehrere Commits aus einem Featurebranch zu einem einzigen Commit zusammengefasst werden, der zu main hinzugefügt wird.

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.

Meldung zum Zusammenführen eines Squashmerge

Beim Squashen und Mergen generiert GitHub eine Standardmeldung für den Commit, die du bearbeiten kannst. Je nachdem, wie das Repository konfiguriert ist und wie viele Commits sich im Pull Request befinden (Mergecommits ausgeschlossen), kann diese Meldung den Titel und die Beschreibung des Pull Request oder Informationen zu den Commits enthalten.

Anzahl der Commits	Zusammenfassung	BESCHREIBUNG
Ein Commit	Der Titel der Commitnachricht für den einzelnen Commit, gefolgt von der Pull Request-Nummer	Der Textkörper der Commitnachricht für den einzelnen Commit
Mehr als ein Commit	Der Titel des Pull Requests gefolgt von der Nummer des Pull Requests	Eine Liste der Commitnachrichten für alle Squash-Commits in der Datumsreihenfolge

Benutzer*innen mit Maintainer- oder Administratorzugriff auf ein Repository können die Standardmergemeldung für alle gesquashten Commits konfigurieren, damit der Pull-Request-Titel, der Pull-Request-Titel und die Commitdetails oder der Titel und die Beschreibung des Pull Request verwendet wird. Weitere Informationen findest du unter Commit-Squashing für Pull Requests konfigurieren.

Squashen und Zusammenführen eines lang ausgeführten Branches

Wenn du die Arbeit am Head-Branch eines Pull Requests fortsetzen möchten, nachdem der Pull Request zusammengeführt wurde, empfehlen wir, den Pull Request nicht zu squashen und zusammenzuführen.

Wenn du einen Pull Request erstellst, identifiziert GitHub den zuletzt verwendeten Commit, der sich sowohl auf dem Head-Branch als auch auf dem Basis-Branch befindet: der gemeinsame Vorgänger-Commit. Wenn du den Pull Request squashst und zusammenführst, erstellt GitHub einen Commit auf dem Basis-Branch, der alle Änderungen enthält, die du seit dem gemeinsamen Vorgänger-Commit vorgenommen hast.

Da sich dieser Commit nur auf dem Basis-Branch und nicht auf dem Head-Branch befindet, bleibt der gemeinsame Vorgänger der beiden Branches unverändert. Wenn du weiterhin am Head-Branch arbeitest, erstellst du dann einen neuen Pull Request zwischen den beiden Branches. Der Pull Request umfasst alle Commits seit dem gemeinsamen Vorgänger, einschließlich Commits, die du im vorherigen Pull Request gesquasht und zusammengeführt hast. Wenn keine Konflikte vorhanden sind, kannst du diese Commits sicher zusammenführen. Dieser Workflow macht jedoch Mergekonflikte wahrscheinlicher. Wenn du weiterhin Squash und Zusammenführen von Pull Requests für einen lang ausgeführten Head-Branch fortsetzt, musst du dieselben Konflikte wiederholt lösen.

Rebasing und Merging von Commits

Wenn du die Option Rebase und Merge für einen Pull Request auf Ihre GitHub Enterprise Server-Instance auswählst, werden alle Commits aus dem Topicbranch (oder Headbranch) ohne einen Mergecommit einzeln im Basisbranch hinzugefügt. Auf diese Weise ähnelt das Verhalten von „Rebase und Merge“ einem Merge mit Vorlauf, indem ein linearer Projektverlauf beibehalten wird. Ein Rebase erreicht dies jedoch durch erneutes Schreiben des Commitverlaufs auf dem Basisbranch mit neuen Commits.

Das Verhalten von „Rebase und Merge“ auf GitHub Enterprise Server weicht etwas von git rebase ab. „Rebase und Merge“ auf GitHub aktualisiert jederzeit die Informationen zum Committer und erstellt neue Commit-SHAs. Demgegenüber ändert git rebase außerhalb von GitHub nicht die Informationen zum Committer, wenn das Rebase zusätzlich zu einem Vorgängercommit erfolgt. Weitere Informationen zu git rebase findest du 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 findest du im Kapitel „Git Branching – Rebasing“ aus dem Pro Git-Buch.

In folgenden Fällen ist kein automatisches Rebasing und Merging auf Ihre 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 du trotzdem ein Rebasing der Commits durchführen möchtest, aber das automatische Rebasing und Merging auf Ihre GitHub Enterprise Server-Instance nicht möglich ist, musst du folgendermaßen vorgehen:

Führe ein Rebasing des Themen-Branches (oder Head-Branches) auf den Basis-Branch lokal in der Befehlszeile durch.
Behebe alle Mergekonflikte in der Befehlszeile.
Erzwinge den Push der Rebase-Commits an den Themen-Branch (oder Remote-Head-Branch) des Pull Requests.

Alle Personen mit Schreibberechtigungen im Repository können dann über die Rebase- und Merge-Schaltfläche auf Ihre GitHub Enterprise Server-Instance die Änderungen mergen.

Indirekte Merges

Ein Pull Request kann automatisch gemergt werden, wenn sein Headbranch extern direkt oder indirekt in den Basisbranch gemergt wird. Anders gesagt: Wenn der Spitzencommit des Headbranchs von der Spitze des Zielbranchs aus erreichbar wird. Beispiel:

Branch main befindet sich bei Commit C.
Branch feature wurde von main verzweigt und befindet sich derzeit im Commit D. Dieser Branch enthält einen Pull Request für main.
Branch feature_2 wurde von feature verzweigt und befindet sich derzeit im Commit E. Dieser Branch enthält ebenfalls einen Pull Request für main.

Wenn Pull Request E --> main zuerst gemergt wird, dann wird Pull Request D --> main automatisch als „gemergt“ markiert, da alle Commits von feature jetzt von main aus erreichbar sind. Beim Mergen von feature_2 in main und Pushen von main zum Server über die Befehlszeile werden beide Pull Requests als „gemergt“ markiert.

Indirekte Merges können nur auftreten, wenn die Commits im Head-Branch des Pull Requests direkt in den Standardbranch des Repositorys gepusht werden oder wenn die Commits im Head-Branch des Pull Requests in einem anderen Pull Request vorhanden sind und mithilfe der Option Merge-Commit erstellen in den Standardbranch des Repositorys gemergt werden.

Wenn ein Pull Request mit Commits, die im Head-Branch eines anderen Pull Requests vorhanden sind, mithilfe der Optionen Squash und Merge oder Rebase und Merge gemergt wird, wird ein neuer Commit im Basisbranch erstellt, und der andere Pull Request wird nicht automatisch gemergt.

Pull Requests, die indirekt gemergt werden, werden auch dann als merged markiert, wenn Branchschutzregeln nicht erfüllt wurden.