Du kannst Merge-Optionen für Pull Requests auf your GitHub Enterprise Server instance konfigurieren, um den Anforderungen und Voreinstellungen Deines Workflow für die Verwaltung des Git-Verlauf zu entsprechen. Weitere Informationen findest Du unter "Pull-Request-Zusammenführungen konfigurieren." 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 Du in einem Pull Request auf your GitHub Enterprise Server instance auf die standardmäßige Option Merge pull request (Pull Request zusammenführen) klickst, werden alle Commits aus dem Feature-Branch zum Basisbranch in einem Merge-Commit hinzugefügt. Der Pull Request wird mithilfe der Option --no-ff zusammengeführt.
Zum Zusammenführen von Pull Requests 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. For more information, see "About protected branches."
Deine Merge-Commits squashen
Wenn Du die Option Squash and merge (Squash und Merge) in einer Abrufanfrage auf your GitHub Enterprise Server instance auswählst, 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 Standardbranch zusammengeführt. Pull Requests mit gesquashten Commits werden mithilfe der Fast-Forward-Option zusammengeführt.
Zum Squashen und Mergen von Pull Requests musst Du im Repository über Schreibberechtigungen verfügen. Zudem muss im Repository Squash-Zusammenführung zulässig sein.
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.
- If you continue working on the head branch of a pull request after squashing and merging, and then create a new pull request between the same branches, commits that you previously squashed and merged will be listed in the new pull request. You may also have conflicts that you have to repeatedly resolve in each successive pull request. Weitere Informationen finden Sie unter „Informationen zum Mergen 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 kann die Verwendung von
git rererenicht so effektiv sein.
Weitere Informationen findest Du unter „Commit-Squashing für Pull Requests konfigurieren.“
Rebasing und Zusammenführen Deiner Commits
Wenn Du die Option Rebase and merge (Rebase und Merge) für einen Pull Request auf your GitHub Enterprise Server instance auswählst, werden alle Commits vom Themen-Branch (oder Head-Branch) ohne einen Merge-Commit einzeln auf dem Basisbranch hinzugefügt. Pull Requests mit Rebased-Commits werden mithilfe der Fast-Forward-Option zusammengeführt.
Für das Rebasing und Mergen von Pull Requests musst Du im Repository über Schreibberechtigungen verfügen. Zudem muss das Repository Rebase-Merging zulassen.
Das Rebase- und Merge-Verhalten auf GitHub Enterprise Server 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. For more information about git rebase, see the official Git documentation.
Eine visuelle Darstellung von git rebase findest Du im Kapitel „Git-Branching - Rebasing“ im Pro Git-Buch.
Bevor Du das Commit-Rebasing aktivierst, sollten Du 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 übertragen, bevor sie die Option Rebase and merge (Rebasing und Zusammenführen) auf your 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 and merge (Rebase und Merge) auf your GitHub Enterprise Server instance deaktiviert ist, sowie zum Workflow, um sie wieder zu aktivieren, findest Du unter „Informationen zum Zusammenführen von Pull Requests.“
Weitere Informationen findest Du unter „Commit-Rebasing für Pull Requests konfigurieren.“