Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.
GitHub AE is currently under limited release.

Informationen zum Zusammenführen von Pull Requests

Du kannst Pull Requests zusammenführen, indem du alle Commits in einem Featurebranch beibehältst, alle Commits per Squash in einen einzigen Commit zusammenführst oder ein Rebasing einzelner Commits vom head-Branch auf den base-Branch durchführst.

Mergen von Commits

Wenn du in einem Pull Request auf your enterprise 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.

Standard-Merge-Commit-Diagramm

Squashen und Mergen von Commits

Wenn du die Option Squash und Merge in einem Pull Request auf your enterprise 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.

Commit-Squashing-Diagramm

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 Standardcommitmeldung, die du bearbeiten kannst. Die Standardnachricht hängt von der Anzahl der Commits im Pull Request ab, ohne Merge-Commits.

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

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 your enterprise 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 AE 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 your enterprise 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 your enterprise 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 your enterprise 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.

Pull Requests werden in diesem Fall auch dann als merged markiert, wenn die Schutzregeln für Branches nicht erfüllt wurden.

Weitere Informationsquellen