Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.

Diese Version von GitHub Enterprise wurde eingestellt am 2023-03-15. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Informationen zu Merge-Methoden auf GitHub

Du kannst Mitwirkenden mit Pushzugriff auf dein Repository das Mergen ihrer Pull Requests auf deine GitHub Enterprise Server-Instanz mit verschiedenen Mergeoptionen erlauben oder eine bestimmte Mergemethode für alle Pull Requests deines Repositorys erzwingen.

Du kannst Mergeoptionen für Pull Requests auf deine GitHub Enterprise Server-Instanz 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 deine GitHub Enterprise Server-Instanz 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.

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 About protected branches.

Deine Merge-Commits squashen

Wenn du die Option Squash und Merge in einem Pull Request auf deine GitHub Enterprise Server-Instanz 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.

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.
  • 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 du die Option Rebase und Merge für einen Pull Request auf deine GitHub Enterprise Server-Instanz 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 deine 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 ausführen und mergen in deine GitHub Enterprise Server-Instanz 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.