Pullanforderungen können auf unterschiedliche Weise zusammengeführt werden. Die beste Strategie hängt davon ab, wie der Repository-Verlauf für Ihr Team aussehen soll und wie viele Details Sie aus dem Pull-Request-Branch beibehalten möchten.
| Strategy | Result | Auswählen, wann |
|---|---|---|
| Zusammenführen des Commits | Behält jeden Commit aus dem Pull-Request-Branch bei und fügt einen expliziten Merge-Punkt hinzu. | Ihr Team legt Wert auf eine vollständige Historie, oder die einzelnen Commits sind für sich genommen aussagekräftig. |
| Squashen und Zusammenführen | Fasst alle Commits im Pull Request zu einem einzigen Commit im Basiszweig zusammen. | Eine Pullanforderung stellt eine logische Änderung dar, insbesondere bei vielen kleinen Fixup-Commits. |
| Neubasis und Zusammenführung | Wendet jeden Commit ohne Merge-Commit auf den Basis-Branch an, sodass ein linearer Verlauf entsteht. | Ihr Team möchte eine lineare Historie, und die Commits sind bereits klar organisiert. |
Zusammenführen Ihrer 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.
Ein Merge-Commit bewahrt den vollständigen Commit-Verlauf des Pull-Request-Branches. Dadurch wird es einfacher, jeden Commit zu sehen, der zu der endgültigen Änderung geführt hat, einschließlich Korrekturen und Zwischenarbeiten. Außerdem wird ein expliziter Zusammenführungspunkt im Basiszweigverlauf erstellt.
Wählen Sie diese Strategie, wenn Ihr Team großen Wert auf eine vollständige Historie legt oder wenn die einzelnen Commits in einem Pull Request für sich genommen aussagekräftig sind.
Squashen und Mergen von 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.
Beim Squashen werden alle Commits im Pull Request zu einem einzigen Commit auf dem Basis-Branch zusammengefasst. Dadurch bleibt der Standardmäßige Verzweigungsverlauf präzise und kann das Scannen später vereinfachen. Der Nachteil dabei ist, dass die zwischenzeitlichen Commits aus dem Pull Request im Basis-Branch nicht als separate Commits erhalten bleiben.
Wählen Sie diese Strategie aus, wenn eine Pullanforderung eine logische Änderung darstellt, insbesondere, wenn die Verzweigung viele kleine Fixup-Commits enthält.
Meldung zur Zusammenführung eines Squash-Merge
Wenn Sie squashen und zusammenführen, generiert GitHub eine Standard-Commit-Nachricht, die Sie bearbeiten können. Die Standardnachricht kann den Titel der Pullanforderung, die Beschreibung der Pullanforderung oder commit-Informationen enthalten, je nach Repositoryeinstellungen und der Anzahl der Commits in der Pullanforderung.
Maintainer und Administratoren können die Standardnachricht für Squash-Commits konfigurieren. Siehe Commit-Squashing für Pull-Requests konfigurieren.
Squashing und Zusammenführen eines langfristig bearbeiteten Branches
Squash-Merging funktioniert am besten für kurzlebige Branches. Wenn Sie nach einem Squash-Merge weiterhin am selben Head-Branch arbeiten, können spätere Pull Requests Commits enthalten, die bereits per Squash-Merge in den Basis-Branch zusammengeführt wurden. Dies kann dazu führen, dass Zusammenführungskonflikte wahrscheinlicher sind und Sie zwingen können, dieselben Konflikte mehrmals aufzulösen.
Erwägen Sie bei langlebigen Branches, einen Merge-Commit zu verwenden oder den Branch neu zu basieren, bevor Sie den nächsten Pull Request öffnen.
Rebasing und Merging von 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. Ein Rebase erreicht dies jedoch durch erneutes Schreiben des Commitverlaufs auf dem Basisbranch mit neuen Commits.
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 Committerinformationen und erstellt neue Commit-SHAs, während
git rebasedie Committerinformationen nicht ändert, wenn das Rebase auf einem Vorgängercommit 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.
Bei einem Rebase wird jeder Commit aus dem Pull-Request-Branch auf den Basis-Branch angewendet, ohne einen Merge-Commit zu erstellen. Dies erzeugt einen linearen Verlauf, wobei die einzelnen Commits aus dem Pull-Request beibehalten werden.
Wählen Sie diese Strategie aus, wenn Ihr Team einen linearen Verlauf wünscht und die Pull-Anforderungs-Commits bereits klar organisiert sind. Wenn GitHub für die Pull-Anforderung nicht sicher automatisch einen Rebase durchführen kann, können Sie den Rebase lokal durchführen, Konflikte beheben und den aktualisierten Branch pushen. Siehe Resolving a merge conflict using the command line und Merging a pull request.
Indirekte Zusammenführungen
Eine Pull-Anforderung kann als zusammengeführt markiert werden, wenn ihre Head Branch-Commits von der Basis-Verzweigung außerhalb dieser Pullanforderung erreichbar werden können. Dies kann passieren, wenn dieselben Commits über einen anderen Pull Request zusammengeführt oder direkt in den Standard-Branch gepusht werden.
Indirekte Zusammenführungen sind ungewöhnlich, können sich jedoch auf Automatisierungs- und Zweigschutzerwartungen auswirken. Zusammengeführte Pullanforderungen werden indirekt als merged auch dann markiert, wenn Verzweigungsschutzregeln für diese Pullanforderung nicht erfüllt waren.