Hallo, Entdecker! An dieser Seite wird aktiv gearbeitet, oder sie wird noch übersetzt. Die neuesten und genauesten Informationen findest Du in unserer englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wird eingestellt am Diese Version von GitHub Enterprise wurde eingestellt am 2020-05-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim Upgrade zu erhalten.

Artikelversion: Enterprise Server 2.17

Informationen zu Merge-Methoden auf GitHub

Du kannst Mitarbeitern mit Push-Zugriff auf Dein Repository erlauben, ihre Pull-Requests auf Ihre GitHub Enterprise Server-Instanz mit verschiedenen Merge-Optionen zusammenzuführen, oder eine bestimmte Merge-Methode für alle Pull-Requests Deines Repositorys erzwingen.

Inhalt dieses Artikels

Du kannst Pull-Request Merge-Optionen auf Ihre GitHub Enterprise Server-Instanz 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." Du kannst eine Art von Merge-Methode erzwingen, beispielsweise Commit-Squashing oder -Rebasing, indem Du nur die gewünschte Methode für Dein Repository aktivierst.

Wenn Du in einem Pull-Request auf Ihre GitHub Enterprise Server-Instanz auf die standardmäßige Option Merge pull request (Pull-Request mergen) klickst, 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 zusammengeführt.

Zum Zusammenführen von Pull-Requests musst Du über Schreibberechtigungen im Repository verfügen.

Standard-Merge-Commit-Diagramm

Deine Merge-Commits squashen

Wenn Du die Option Squash and merge (Squash und Merge) in einer Abrufanfrage auf Ihre GitHub Enterprise Server-Instanz 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 Standard-Branch zusammengeführt. Pull-Requests mit gesquashten Commits werden mithilfe der Fast-Forward-Option zusammengeführt.

Zum Squashen und Zusammenführen von Pull-Requests musst Du im Repository über Schreibberechtigungen verfügen. Zudem muss im Repository Squash-Zusammenführung zulässig sein.

Commit-Squashing-Diagramm

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.
  • 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 rerere nicht 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 Ihre GitHub Enterprise Server-Instanz auswählst, 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 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 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 findest Du im Kapitel zu „Git rebase“ im Pro Git-Buch.

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 Ihre GitHub Enterprise Server-Instanz 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 Ihre GitHub Enterprise Server-Instanz 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.“

Menschliche Unterstützung einholen

Du kannst das Gesuchte nicht finden?

Kontakt