Ein Merge-Konflikt kann den Arbeitsfluss sofort stoppen, besonders wenn bereits Dateien mit Konfliktmarkierungen gefüllt sind. Der Ausdruck git abort merge meint in der Praxis fast immer den Befehl git merge --abort, mit dem ich einen laufenden Merge möglichst sauber abbreche. Hier zeige ich, wann der Befehl funktioniert, welche Änderungen erhalten bleiben und was bei einem bereits abgeschlossenen Merge zu tun ist.
Mit wenigen Befehlen zurück zum Zustand vor dem Merge
-
Abbruch:
git merge --abortbeendet einen laufenden Merge-Vorgang. - Voraussetzung: Der Merge muss noch aktiv sein, etwa wegen eines Konflikts oder eines ausstehenden Merge-Commits.
- Vorsicht: Uncommittete Änderungen vor dem Merge lassen sich nicht in jedem Fall vollständig wiederherstellen.
- Alternative: Bei einer laufenden Rebase- oder Cherry-Pick-Operation gelten andere Abbruchbefehle.
-
Nach einem Commit: Ein bereits abgeschlossener Merge wird nicht mit
merge --abort, sondern meist mitgit revertrückgängig gemacht.
Was beim Abbruch tatsächlich zurückgesetzt wird
Während eines Merges versucht Git, die Änderungen zweier Entwicklungszweige zusammenzuführen. Entsteht ein Konflikt, bleibt der aktuelle Branch normalerweise auf seinem bisherigen Commit stehen, während der Index und die Arbeitsdateien teilweise den begonnenen Merge widerspiegeln.
git merge --abort beendet diesen Vorgang und versucht, den Zustand vor dem Merge wiederherzustellen. Dabei entfernt Git den aktiven Merge-Zustand und die Konfliktmarkierungen, ohne den anderen Branch zu verändern. In einem normalen Szenario lande ich danach wieder genau an dem Punkt, an dem ich den Merge gestartet habe.
Das Wort „versucht“ ist dabei entscheidend. Wenn vor dem Merge bereits uncommittete Änderungen vorhanden waren und diese während des Konflikts weiter verändert wurden, kann Git den ursprünglichen Zustand nicht immer eindeutig rekonstruieren. Deshalb sollte ein Arbeitsbaum vor einem größeren Merge möglichst sauber sein.
So führe ich den sicheren Abbruch durch
Zuerst prüfe ich den aktuellen Zustand des Repositorys. Die Ausgabe zeigt, ob tatsächlich ein Merge läuft und welche Dateien betroffen sind.
git statusSteht dort beispielsweise, dass ein Merge wegen Konflikten noch nicht abgeschlossen ist, reicht in der Regel dieser Befehl:
git merge --abortDanach kontrolliere ich den Zustand erneut:
git statusDie Konfliktdateien sollten nun wieder verschwunden sein. Ein anschließendes git diff hilft mir zu prüfen, ob noch lokale Änderungen vorhanden sind. Gerade bei wichtigen Dateien verlasse ich mich nicht nur auf eine erfolgreiche Meldung im Terminal, sondern kontrolliere kurz, ob der Arbeitsbaum tatsächlich dem erwarteten Zustand entspricht.
Der typische Ablauf an einem Beispiel
git switch main
git merge feature-login
# Git meldet Konflikte
git status
# Entscheidung gegen den Merge
git merge --abort
# Kontrolle
git statusDer Befehl git merge --abort löscht dabei nicht den Branch feature-login. Er verwirft nur den aktuell begonnenen Zusammenführungsversuch. Das ist ein wichtiger Unterschied, denn der andere Branch bleibt vollständig erhalten und kann später erneut, möglicherweise nach einer Anpassung, gemergt werden.
Wenn lokale Änderungen oder ein Autostash im Spiel sind
Git warnt nicht ohne Grund davor, einen Merge mit umfangreichen uncommitteten Änderungen zu starten. Überschneiden sich lokale Änderungen und die Änderungen des anderen Branches, kann der Rückweg unübersichtlich werden. Meine bevorzugte Reihenfolge lautet deshalb committen, stashen oder erst danach mergen.
git status
git add .
git commit -m "Lokalen Arbeitsstand sichern"
git merge feature-loginWenn ein Commit noch nicht sinnvoll ist, kann ich die Änderungen vorübergehend speichern:
git stash push -u -m "Vor Merge gesicherte Änderungen"
git merge feature-loginDie Option -u nimmt auch nicht versionierte Dateien in den Stash auf. Das ist praktisch, wenn neben bearbeiteten Dateien auch neue lokale Dateien geschützt werden sollen. Nach einem erfolgreichen oder abgebrochenen Merge lassen sich die Änderungen mit git stash pop wieder anwenden. Dabei können allerdings erneut Konflikte entstehen.
Lesen Sie auch: Conda vs. pip - Die beste Wahl für dein Python-Projekt?
Was passiert bei aktiviertem Autostash
Wurde der Merge mit einer automatischen Ablage lokaler Änderungen gestartet, versucht git merge --abort, diesen Autostash wieder auf den Arbeitsbaum anzuwenden. Scheitert das wegen neuer Konflikte, bleibt der Stash normalerweise erhalten und sollte mit git stash list kontrolliert werden.
Wenn nach dem Abbruch Dateien fehlen oder unerwartet verändert aussehen, sichere ich den aktuellen Zustand zunächst separat, bevor ich weitere Reset-Befehle ausführe. Besonders git reset --hard ist kein harmloser Reparaturversuch, sondern kann nicht committete Änderungen unwiederbringlich entfernen.
Abort, quit oder continue richtig unterscheiden
Git bietet für einen angehaltenen Merge drei unterschiedliche Wege. Ich wähle sie danach aus, ob ich den Vorgang verwerfen, nur den Merge-Zustand entfernen oder den Merge fertigstellen möchte.
| Befehl | Wirkung | Wann sinnvoll |
|---|---|---|
git merge --abort |
Bricht den Merge ab und stellt den Zustand vor dem Merge möglichst wieder her. | Wenn die Zusammenführung nicht weitergeführt werden soll. |
git merge --quit |
Vergisst den aktiven Merge-Zustand, lässt Index und Arbeitsbaum aber unverändert. | Wenn ich die aktuelle Konfliktbearbeitung bewusst behalten möchte. |
git merge --continue |
Setzt den Merge nach der Konfliktlösung fort. | Wenn alle Konflikte behoben und die Dateien mit git add markiert wurden. |
Nach einer Konfliktlösung sieht der normale Abschluss etwa so aus:
git add src/login.js
git status
git merge --continueIn manchen Konfigurationen öffnet Git dabei den Editor für die Merge-Commit-Nachricht. Das ist kein Fehler, sondern der letzte Schritt vor dem Abschluss. Ich breche diesen Vorgang nur ab, wenn die Konfliktlösung selbst fragwürdig ist oder sich die Zielrichtung des Branches geändert hat.
Wenn der Abbruch nicht möglich ist
Meldet Git, dass kein Merge läuft, liegt oft eine andere Operation vor. Eine Rebase wird mit git rebase --abort beendet, ein Cherry-Pick mit git cherry-pick --abort. Die Befehle sehen ähnlich aus, greifen aber auf unterschiedliche interne Zustände zurück.
git status
git rebase --abortWenn Git keinen aktiven Merge erkennt, obwohl die Dateien Konfliktmarkierungen enthalten, sollte ich nicht blind einen harten Reset ausführen. Zuerst prüfe ich mit git log --oneline --decorate -5 und git diff, ob bereits ein Commit entstanden ist oder ob lediglich manuelle Änderungen im Arbeitsbaum liegen.
Als technische Alternative existiert git reset --merge. Bei einem aktiven Merge entspricht es in vielen Fällen dem Abbruchbefehl. Die Behandlung eines vorhandenen Autostashes kann sich jedoch unterscheiden, weshalb ich im normalen Arbeitsablauf git merge --abort bevorzuge.
Was nach einem abgeschlossenen Merge gilt
git merge --abort funktioniert nur, solange der Merge noch läuft. Wurde bereits ein Merge-Commit erzeugt, muss ich diesen Commit wie jede andere Änderung rückgängig machen. Dafür ist meistens git revert die sicherere Lösung, besonders wenn der Commit schon in ein gemeinsames Remote-Repository gepusht wurde.
git log --oneline --graph -5
git revert -m 1 Die Option -m 1 teilt Git mit, welcher Eltern-Commit als Hauptlinie gelten soll. Bei einem Merge von feature-login in main ist das häufig der Commit aus main. Die Auswahl muss ich trotzdem anhand der tatsächlichen Historie prüfen, denn ein falscher Haupt-Parent kann ein unerwartetes Ergebnis erzeugen.
Ein nachträgliches git reset --hard kann lokal zwar ebenfalls auf einen früheren Stand zeigen, verändert aber die Branch-Historie. Auf gemeinsam genutzten Branches erzeugt das unnötige Probleme. Ich verwende diese Variante nur, wenn der Commit ausschließlich lokal existiert und die Konsequenzen eindeutig sind.
Der kurze Entscheidungsweg für den nächsten Merge
Solange der Merge noch läuft und verworfen werden soll, ist git merge --abort der richtige erste Schritt. Bei lokalen Änderungen prüfe ich vorher den Arbeitsbaum, bei einer Rebase oder einem Cherry-Pick verwende ich den jeweils passenden Abbruchbefehl. Ist der Merge bereits committed, entscheide ich zwischen einem sicheren Revert und einer lokalen Historienkorrektur, statt den laufenden Merge-Befehl weiter zu erzwingen.
