Anwenden von Änderungen durch einen Rebase

2025-03-31

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git verwaltet automatisch einen Verlauf Ihrer Entwicklungen in einem Branch, indem jeder neue Commit mit seinem Vorgänger verknüpft wird. Wenn Sie einen Branch mit einem anderen mergen, kann der Verlauf unübersichtlicher werden. Beispiel: Ein No-Fast-Forward-Merge kombiniert divergente Entwicklungslinien, indem ein Mergecommit mit mehreren Vorgängern erstellt wird. Umgekehrt kombiniert ein Git-rebase divergierende Entwicklungslinien ohne Erstellen eines Zusammenführungs-Commits, was zu einem einfacheren Commit-Verlauf führt, aber Informationen über die Zusammenführung verliert. Welchen Mergetyp Sie auswählen, hängt wahrscheinlich davon ab, ob Sie eine Aufzeichnung des Mergevorgangs beibehalten oder den Commitverlauf vereinfachen möchten.

In diesem Artikel wird erläutert, wann anstelle eines No-Fast-Forward-Mergevorgangs ein Rebase verwendet werden sollte. Außerdem werden Verfahren für die folgenden Aufgaben beschrieben:

Ausführen eines Rebase-Vorgangs für Ihren lokalen Branch
Ausführen eines Force Push-Vorgangs für Ihren lokalen Branch nach einem Rebase
Ausführen eines interaktiven Rebase-Vorgangs zum Squashen lokaler Commits

Eine Übersicht über den Git-Workflow finden Sie im Azure Repos Git-Lernprogramm.

Voraussetzungen

Kategorie	Anforderungen
Projektzugriff	Mitglied eines Projekts.
Berechtigungen	- Code in einem privaten Projekt anzeigen: Mindestens Basic-Zugriff. - Code in privaten Projekten klonen oder dazu beitragen: Mitglied der Sicherheitsgruppe Contributors oder entsprechende Berechtigungen im Projekt. – Verzweigungs- oder Repository-Berechtigungen festlegen: Berechtigungen Berechtigungen verwalten für die Verzweigung oder das Repository. - Standardbranch ändern: Berechtigungen Richtlinien bearbeiten für das Repository. - Ein Repository importieren: Mitglied der Sicherheitsgruppe Projektadministratoren oder auf Git-Projektebene die Berechtigung Repository erstellen auf Zulassen festgelegt. Weitere Informationen finden Sie unter Festlegen von Git-Repositoryberechtigungen.
Dienstleistungen	Repositorys aktiviert.
Tools	Wahlfrei. Verwenden von az repos-Befehlen: Azure DevOps CLI.

Hinweis

In öffentlichen Projekten haben Benutzer*innen mit Beteiligten -Zugriff vollen Zugriff auf Azure Repos, einschließlich Anzeigen, Klonen und Beitragen zum Code.

Kategorie	Anforderungen
Projektzugriff	Mitglied eines Projekts.
Berechtigungen	- Code anzeigen: Mindestens Basis-Zugriff. - Code klonen oder dazu beitragen: Mitglied der Sicherheitsgruppe Beitragende oder entsprechende Berechtigungen im Projekt.
Dienstleistungen	Repositorys aktiviert.

Ausführen eines Rebase-Vorgangs für Ihren lokalen Branch

Git Rebase integriert Commits aus einem Quellbranch in Ihren aktuellen lokalen Branch (Zielbranch). Der Quellzweig bleibt unverändert. Zum Vergleich werden git rebase und andere Zusammenführungstypen im folgenden Diagramm dargestellt.

Diagramm: Commits vorher und nachher bei Verwendung von Git Rebase

Bei Git Rebase wird der Commitverlauf des Zielbranchs neu sequenziert, sodass er alle Commits im Quellbranch gefolgt von allen Commits im Zielbranch seit dem letzten gemeinsamen Commit enthält. Eine weitere Möglichkeit dafür besteht darin, dass ein Rebasevorgang die Änderungen in Ihrem Zielbranch über dem Quellbranchverlauf wiederholt. Insbesondere ändert Git Rebase die Reihenfolge der vorhandenen Commits im Zielbranch, was bei den anderen Mergestrategien nicht der Fall ist. Im vorherigen Diagramm enthält commit K' die gleichen Änderungen wie K, verfügt aber über eine neue Commit-ID, da sie mit dem Commit E anstelle von C verknüpft wird.

Wenn während eines Rebasevorgangs eine Quellbranchänderung einer Zielbranchänderung widerspricht, werden Sie von Git aufgefordert, den Mergekonflikt zu beheben. Sie können Mergekonflikte während eines Rebasevorgangs auf dieselbe Weise lösen wie Mergekonflikte während eines Mergevorgangs.

Rebase und No-Fast-Forward-Merge im Vergleich

Git Rebase führt zu einem einfacheren, aber weniger exakten Commitverlauf als ein No-Fast-Forward-Merge, der auch als Drei-Wege- oder True-Merge bezeichnet wird. Wenn Sie eine Aufzeichnung eines Mergevorgangs im Commitverlauf verwenden möchten, führen Sie einen No-Fast-Forward-Merge aus.

Wenn Sie die einzige Person sind, die an einem Feature- oder Bugfixbranch arbeitet, sollten Sie ein Rebase verwenden, um aktuelle Arbeit aus dem main-Branch regelmäßig darin zu integrieren. Mit dieser Strategie können Sie sicherstellen, dass Sie die aktuellen Arbeiten anderer Personen kennen und alle Merge-Konflikte, die auftreten, umgehend lösen. Durch die Ausführung eines Rebase implementieren Sie Ihr neues Feature oberhalb der letzten Arbeit im main-Branch, wodurch Sie einen linearen Commitverlauf erhalten.

Weitere Informationen zu Git-Rebase und wann es verwendet wird, finden Sie unter Rebase vs Merge.

Richtlinien zu Rebase und Force Push

Wenn Sie für einen lokalen Branch, den Sie zuvor gepusht haben, ein Rebase ausführen und dann den standardmäßigen Git Push-Befehl erneut ausführen, schlägt der Pushvorgang fehl. Durch den standardmäßigen Git Push-Befehl wird ein Fast-Forward-Merge angewendet, um Ihren lokalen Branch in den Remotebranch zu integrieren. Dieser Befehl schlägt nach einem Rebase fehl, da die Reihenfolge vorhandener Commits in Ihrem lokalen Zielbranch vom Rebasevorgang geändert wird, sodass er nicht mehr mit dem Verlauf des entsprechenden Remotebranchs übereinstimmt. In diesem Szenario ist Force Push erfolgreich, indem der Remotebranch überschrieben wird.

Git-Rebase und Force-Push sind mächtige Werkzeuge, aber beachten Sie diese Richtlinien, wenn Sie entscheiden, ob Sie sie verwenden:

Führen Sie keinen Rebase für einen lokalen Branch aus, der gepusht und für andere freigegeben wurde, es sei denn, Sie sind sicher, dass der freigegebene Branch von niemandem verwendet wird. Nach einem Rebase stimmt Ihr lokaler Branch nicht mehr mit dem Verlauf seines entsprechenden Remotebranchs überein.
Führen Sie keinen Force Push auf einen Remotebranch aus, der von anderen verwendet wird, da die lokale Version des Remotebranchs nicht mehr mit dem Verlauf des aktualisierten Remotebranchs übereinstimmt.
Ihr Team sollte sich auf die Nutzungsszenarien für rebasen und force push einigen.

Tipp

Verwenden Sie für einen gemeinsamen Überprüfungsprozess einen Pull Request, um neue Arbeit in den Standardbranch eines Remoterepositorys zu mergen.

So führen Sie einen Rebase aus

Visual Studio 2022 bietet eine Git-Versionskontrolle mithilfe des Git--Menüs, Git Changesund über Kontextmenüs im Projektmappen-Explorer. Visual Studio 2019, Version 16.8, bietet auch die Team Explorer Git-Benutzeroberfläche. Weitere Informationen finden Sie auf der Registerkarte Visual Studio 2019 – Team Explorer.

Wählen Sie Git > Manage Branches aus, um das Fenster Git Repository zu öffnen.
Klicken Sie im Fenster Git-Repository mit der rechten Maustaste auf den Zielbranch, und wählen Sie Check-Out aus.
Klicken Sie mit der rechten Maustaste auf den Quellbranch, und wählen Sie Rebase für <Zielbranch> ausführen auf <Quellbranch> aus.
Visual Studio zeigt nach einer erfolgreichen Neubasis eine Bestätigungsmeldung an.

Wenn der Rebasevorgang aufgrund von Mergekonflikten angehalten wird, werden Sie von Visual Studio benachrichtigt. Sie können entweder Konflikte lösen oder den Rebasevorgang abbrechen und zum Zustand vor dem Rebasevorgang zurückkehren.

Führen Sie den Befehl git rebase aus, um Quell-Zweig-Commits in einen Zielzweig zu integrieren.

git rebase <source branch name> <target branch name>

Wenn Ihr aktueller lokaler Branch der Zielbranch ist, können Sie den Rebase-Befehl wie folgt vereinfachen:

git rebase <source branch name>

Git benachrichtigt Sie, wenn während der Rebase Konflikte auftreten. Sie können entweder die Konflikte lösen und dann git rebase --continue ausführen, oder Sie können git rebase --abort ausführen, um den Rebasevorgang rückgängig zu machen und zum Zustand vor dem Rebase zurückzukehren.

Ausführen eines Force Push-Vorgangs für Ihren lokalen Branch nach einem Rebase

Wenn Sie ein Rebase für einen lokalen Branch ausführen, den Sie zuvor gepusht haben, verursacht ein nachfolgender standardmäßiger Git Push einen Fehler. Stattdessen können Sie für Ihren lokalen Branch einen Force Push ausführen, um seinen entsprechenden Remotebranch zu überschreiben, damit ihre Commitverläufe übereinstimmen.

Warnung

Ein Force Push darf niemals für einen Branch ausgeführt werden, an dem andere arbeiten. Weitere Informationen finden Sie unter Richtlinien zu Rebase und Force Push.

Um den Push in Visual Studio zu erzwingen, müssen Sie zuerst die Option "Push erzwingen" aktivieren:

Wechseln Sie zu Tools>Optionen>Quellcodeverwaltung>Git Global Settings.
Wählen Sie die Option „push --force-with-lease“ aktivieren aus.

Das --force-with-lease-Flag von Git Push ist sicherer als das --force-Flag, da es keinen Remotebranch überschreibt, der Commits enthält, die nicht in den lokalen Branch integriert sind, für den Sie einen Force Push ausführen.

Wählen Sie im Fenster Git-Änderungen die Schaltfläche „Pushen“ aus, um den Commit zu pushen.

Alternativ können Sie Push im Menü Git auswählen.
Wenn der Standard-Git-Pushvorgang fehlschlägt, startet Visual Studio das Dialogfeld Git-Push 'fehlgeschlagen'. Wählen Sie Push erzwingen aus.
Visual Studio zeigt nach einem erfolgreichen Push eine Bestätigungsmeldung an.

Tipp

So führen Sie einen Force Push für neue Commits von Ihrem lokalen Branch in einen gleichnamigen Remotebranch aus:

git push --force-with-lease <remote> <local branch name>

Wenn der Branch, den Sie pushen möchten, Ihr ausgecheckter Branch ist, können Sie den Force Push-Befehl wie folgt vereinfachen:

git push --force-with-lease <remote>

Wenn Sie ein Remote-Repository klonen, weist Git den Alias origin als Abkürzung für die URL des Remote-Repositorys zu, das Sie geklont haben. Führen Sie git remote -v aus, um den origin Aliaswert zu überprüfen. Um den origin-Alias manuell hinzuzufügen, führen Sie git remote add origin <remote repo url>aus. Mit dem origin Alias können Sie den Force-Pushbefehl weiter vereinfachen:

git push --force-with-lease origin

Wenn Ihr aktueller lokaler Branch einen Remotebranch auf origin nachverfolgt, können Sie den Force Push-Befehl vollständig abkürzen:

git push --force-with-lease

Der vollkommen abgekürzte Push-Befehl schlägt jedoch fehl, wenn Ihr lokaler Branch keinen Remote-Branch nachverfolgt. Führen Sie git remote show origin aus, um den Nachverfolgungsstatus Ihrer Branches zu überprüfen.

Ausführen eines interaktiven Rebase-Vorgangs zum Squashen lokaler Commits

Normalerweise erstellen Sie während der Arbeit an einem neuen Feature in Ihrem lokalen Featurezweig mehrere Commits. Wenn Sie bereit sind, die neue Funktion zu veröffentlichen, sollten Sie diese Commits in einem einzigen Commit zusammenfassen, um die Commit-Historie zu vereinfachen. Sie können einen interaktiven Rebase-Befehl verwenden, um mehrere Commits in einem einzelnen Commit zu squashen.

Visual Studio 2022 unterstützt keine interaktive Neubasierung. Verwenden Sie stattdessen die Git-Befehlszeile.

Checken Sie den lokalen Branch aus, für den Sie einen interaktiven Rebasevorgang ausführen möchten.
Committen, Stashen oder Verwerfen aller nicht committeten Änderungen.
Schätzen Sie, wie weit sie im Commitverlauf zurückgehen möchten. Sie müssen nicht genau sein, da Sie beim Ausführen des interaktiven Rebase-Befehls die Commits auswählen können, die Sie squashen möchten. Wenn Sie beispielsweise Commits innerhalb der letzten fünf Commits squashen möchten, führen Sie folgenden Befehl aus:
```
git rebase -i HEAD~5
```
Git öffnet einen Editor, der die letzten fünf Commits auflistet, beginnend mit der neuesten. Beispiel:
```
pick 7068b09 Update README network switch section
pick 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
pick 00859d9 Add network controller test
```
Lassen Sie die erste Zeile wie folgt. In den folgenden Zeilen, um einen Commit mit dem darüberliegenden zusammenzuführen, ändern Sie pick zu squash. Wenn Sie z. B. die beiden oberen Commits und die beiden unteren Commits kombinieren möchten, ändern Sie die Commitliste wie:
```
pick 7068b09 Update README network switch section
squash 9d247f7 Update README network controller section
pick 5d7ab9f Fix fiber optic transmitter test
pick 7b43f3f Add network switch test
squash 00859d9 Add network controller test
```
Speichern und schließen Sie den Editor. Git öffnet dann einen neuen Editor für jede Gruppe zusammengeführter Commits und fordert Sie auf, eine Commit-Nachricht einzugeben. Fassen Sie die Commitnachrichten für jeden Commitsatz in einer Nachricht zusammen, und speichern und schließen Sie den Editor. Im vorherigen Beispiel werden die gesquashten Commits mit neuen Commitnachrichten zusammengefasst:
```
8fcb88f Update README network sections
ac6d3c0 Fix fiber optic transmitter test
f0aadc3 Add two network tests
```
Obwohl der Fix fiber optic transmitter test-Commit nicht gesquasht wurde, verfügt er über eine neue Commit-ID, da er jetzt mit einem anderen Vorgängercommit verknüpft ist.

Weitere Informationen zu interaktiven Rebasevorgängen finden Sie unter Git Rebase im interaktiven Modus ausführen.

Hinweis

Azure DevOps-Benutzer können einen Squashmerge ausführen, um den Commitverlauf eines Topic-Branchs während eines Pull Requests zusammenzufassen.

Nächste Schritte

Kopieren von Änderungen durch einen Cherry-Pick