Informationen zu Merge-Methoden auf GitHub

Sie können Mitwirkenden mit Pushzugriff auf Ihr Repository das Mergen ihrer Pull Requests mit verschiedenen Mergeoptionen erlauben oder eine bestimmte Mergemethode für alle Pull Requests deines Repositorys erzwingen.

In diesem Artikel

Sie können Mergeoptionen für Pull Requests konfigurieren, um Ihre Workflowanforderungen zu erfüllen und den Voreinstellungen für die Verwaltung des Git-Verlaufs zu entsprechen. Weitere Informationen finden Sie unter „Pull-Request-Merges konfigurieren“. Du kannst eine Art von Mergemethode (z. B. Commitsquashing oder Rebasing) erzwingen, indem du nur die gewünschte Methode für dein Repository aktivierst.

Hinweis: Wenn du die Mergewarteschlange verwendest, kannst du die Mergemethode nicht mehr auswählen, weil diese von der Warteschlange gesteuert wird. Weitere Informationen zu Mergewarteschlangen findest du unter Verwalten einer Mergewarteschlange.

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.

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

Die Standard-Mergemethode erzeugt einen Merge-Commit. Du kannst verhindern, dass Merge-Commits an einen geschützten Branch übertragen werden, indem du einen linearen Commit-Verlauf erzwingst. Weitere Informationen findest du unter Informationen zu geschützten Branches.

Deine Merge-Commits squashen

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.

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.

Bevor du das Commit-Squashing aktivierst, solltest du diese Nachteile berücksichtigen:

  • Du verlierst Informationen darüber, wann bestimmte Änderungen ursprünglich vorgenommen wurden und wer die Squash-Commits erstellt hat.
  • Wenn du nach dem Sqashen und Mergen die Arbeit am Headbranch eines Pull Requests fortsetzt und dann einen neuen Pull Request zwischen denselben Branches erstellst, werden zuvor gesquashte und gemergte Commits im neuen Pull Request aufgeführt. Möglicherweise treten auch Konflikte auf, die du in jedem nachfolgenden Pull Request wiederholt auflösen musst. Weitere Informationen findest du unter Informationen zum Zusammenführen von Pull Requests.
  • Die Verwendung einiger Git-Befehle mit der „SHA“- oder „hash“-ID kann schwieriger sein, da die SHA-ID für die ursprünglichen Commits verloren geht. Beispielsweise ist die Verwendung von git rerere unter Umständen nicht so effektiv.

Weitere Informationen findest du unter Commit-Squashing für Pull Requests konfigurieren.

Rebasing und Zusammenführen deiner Commits

Wenn Sie die Option Rebase und Merge für einen Pull Request auswählen, 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 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.

Bevor du das Commit-Rebasing aktivierst, sollten du diese Nachteile berücksichtigen:

  • Repositorymitarbeiter müssen unter Umständen ein Rebase in der Befehlszeile ausführen, Konflikte beheben und das Pushen ihrer Änderungen an den Topic-Branch (oder Remoteheadbranch) des Pull Requests erzwingen, damit sie die Option Rebase ausführen und mergen auf GitHub verwenden können. Das Erzwingen eines Push muss mit Vorsicht durchgeführt werden, damit die Mitarbeiter die Arbeit nicht überschreiben, auf der andere ihre Arbeit aufgebaut haben. Weitere Informationen dazu, wann die Option Rebase ausführen und mergen in GitHub deaktiviert wird, sowie zum Workflow für das erneute Aktivieren der Option finden Sie unter „Informationen zum Zusammenführen von Pull Requests“.

  • Wenn du die Option Rebase und Merge für einen Pull Request verwendest, ist es wichtig zu wissen, dass die Commits im Headbranch ohne Überprüfung der Commitsignatur dem Basisbranch hinzugefügt werden. Wenn du diese Option verwendest, erstellt GitHub einen geänderten Commit unter Verwendung der Daten und des Inhalts des ursprünglichen Commits. Das bedeutet, dass GitHub diesen Commit nicht wirklich erstellt hat und ihn daher nicht als generischer Systembenutzer signieren kann. GitHub hat keinen Zugriff auf die privaten Signaturschlüssel des Committers und kann daher den Commit nicht im Auftrag des Benutzers signieren.

    Ein Workaround dafür ist, dass du lokal einen Rebase- und Mergevorgang durchführst und die Änderungen dann in den Basisbranch des Pull Requests pushst.

Weitere Informationen findest du unter „Commit-Rebasing für Pull-Requests konfigurieren“.