Du kannst Mergeoptionen für Pull Requests auf Ihre GitHub Enterprise Server-Instance konfigurieren, um deine Workflowanforderungen zu erfüllen und den Voreinstellungen für die Verwaltung des Git-Verlaufs zu entsprechen. Weitere Informationen findest du 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.
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.
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 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.
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 rerereunter Umständen nicht so effektiv.
Weitere Informationen findest du unter Commit-Squashing für Pull Requests konfigurieren.
Rebasing und Zusammenführen deiner 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.
Bevor du das Commit-Rebasing aktivierst, sollten du diese Nachteile berücksichtigen:
-
Mitwirkende an Repositorys müssen möglicherweise ein Rebase an der Befehlszeile ausführen, Konflikte beheben und das Pushen ihrer Änderungen an den Topicbranch (oder Remoteheadbranch) des Pull Requests erzwingen, bevor sie die Option Rebase ausführen and mergen auf Ihre GitHub Enterprise Server-Instance 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 Ihre GitHub Enterprise Server-Instance deaktiviert wird, sowie zum Workflow für das erneute Aktivieren der Option findest du 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“.