Informationen zu Merge-Methoden auf GitHub
Sie können Mitarbeitern mit Push-Zugriff auf Ihr Repository erlauben, ihre Pull Requests auf Ihre GitHub Enterprise Server-Instanz mit verschiedenen Merge-Optionen zu mergen, oder eine bestimmte Merge-Methode für alle Pull Requests Ihres Repositorys erzwingen.
Inhalt dieses Artikels
You can configure pull request merge options on Ihre GitHub Enterprise Server-Instanz to meet your workflow needs and preferences for managing Git history. For more information, see "Configuring pull request merges." Sie können eine Art von Merge-Methode, beispielsweise Commit-Squashing oder Rebasing, erzwingen, indem Sie nur die gewünschte Methode für Ihr Repository aktivieren.
Wenn Sie in einem Pull Request auf Ihre GitHub Enterprise Server-Instanz auf die standardmäßige Option Merge pull request (Pull Request mergen) klicken, werden alle Commits aus dem Feature-Branch zum Basis-Branch in einem Merge-Commit hinzugefügt. Der Pull Request wird mithilfe der Option --no-ff gemergt.
Zum Mergen von Pull Requests müssen Sie über Schreibberechtigungen im Repository verfügen.
Ihre Merge-Commits squashen
Wenn Sie die Option Squash and merge (Squash und Merge) in einer Abrufanfrage auf Ihre GitHub Enterprise Server-Instanz auswählen, werden die Commits der Abrufanfrage in einen einzelnen Commit gesquasht. Anstatt dass alle einzelnen Commits eines Mitarbeiters aus einem Themen-Branch angezeigt werden, werden die Commits in einem Commit kombiniert und in den Standard-Branch gemergt. Abrufanfragen mit gesquashten Commits werden mithilfe der Fast-Forward-Option gemergt.
Zum Squashen und Mergen von Abrufanfragen müssen Sie im Repository über Schreibberechtigungen verfügen. Zudem muss im Repository Squash-Merging zulässig sein.
Mittels Squash und Merge können Sie einen optimierten Git-Verlauf in Ihrem Repository erstellen. In Arbeit befindliche Commits sind hilfreich, wenn Sie auf einem Feature-Branch arbeiten. Sie müssen jedoch nicht unbedingt im Git-Verlauf beibehalten werden. Wenn Sie diese Commits in einen Commit squashen, während Sie ein Merging zum Standardbranch vornehmen, können Sie die ursprünglichen Änderungen in einem leeren Git-Verlauf beibehalten.
Bevor Sie das Commit-Squashing aktivieren, sollten Sie diese Nachteile berücksichtigen:
- Sie verlieren Informationen darüber, wann bestimmte Änderungen ursprünglich vorgenommen wurden und wer die Squash-Commits erstellt hat.
- Die Verwendung einiger Git-Befehle mit der ID „SHA“ oder „hash“ kann schwieriger sein, da die SHA-ID für die ursprünglichen Commits verloren geht. Die Verwendung von
git rerereist beispielsweise unter Umständen nicht so effektiv.
Weitere Informationen finden Sie unter „Commit-Squashing für Pull Requests konfigurieren“.
Rebase und Merge Ihrer Commits
Wenn Sie die Option Rebase and merge (Rebase und Merge) für einen Pull Request auf Ihre GitHub Enterprise Server-Instanz auswählen, werden alle Commits vom Themen-Branch (oder Head-Branch) ohne einen Merge-Commit einzeln auf dem Basis-Branch hinzugefügt. Pull Requests mit Rebased-Commits werden mithilfe der Fast-Forward-Option gemergt.
Für das Rebasing und Mergen von Pull Requests müssen Sie im Repository über Schreibberechtigungen verfügen. Zudem muss im Repository das Rebase-Merging zulässig sein.
Das Rebase- und Merge-Verhalten auf GitHub Enterprise weicht etwas von git rebase ab. Rebase und Merge auf GitHub aktualisiert jederzeit die Informationen zum Beitragenden und erstellt neue Commit-SHAs. Demgegenüber ändert git rebase außerhalb von GitHub nicht die Informationen zum Beitragenden, wenn das Rebasing zusätzlich zu einem Vorgänger-Commit erfolgt. Weitere Informationen zu git rebase finden Sie im Kapitel zu „Git rebase“ im Pro Git-Buch.
Eine visuelle Darstellung von git rebase finden Sie im Kapitel „Git-Branching - Rebasing“ im Pro Git-Buch.
Bevor Sie das Commit-Rebasing aktivieren, sollten Sie diese Nachteile berücksichtigen:
- Repository-Mitarbeiter müssen unter Umständen ein Rebasing in der Befehlszeile durchführen, Konflikte beheben und ihre Änderungen an den Themen-Branch (oder Remote-Head-Branch) des Pull Requests erzwingen und pushen, bevor sie die Option Rebase and merge (Rebase und Merge) auf Ihre GitHub Enterprise Server-Instanz verwenden können. Der erzwungene Push muss mit Vorsicht durchgeführt werden, damit die Mitarbeiter die Arbeit, auf der andere ihre Arbeit aufgebaut haben, nicht überschreiben. Weitere Informationen dazu, wann die Option Rebase and merge (Rebase und Merge) auf Ihre GitHub Enterprise Server-Instanz deaktiviert ist, sowie zum Workflow, um sie wieder zu aktivieren, finden Sie unter „Informationen zum Mergen von Pull Requests“.
Weitere Informationen finden Sie unter „Commit-Rebasing für Pull Requests konfigurieren“.