Ein Merge läuft durch, Tests sind grün – und trotzdem steht plötzlich „CONFLICT“ im Terminal. Das ist kein Zeichen von „kaputtem Git“, sondern eine normale Situation: Git kann zwei Änderungen nicht automatisch zusammenführen, weil sie sich gegenseitig beeinflussen. Wer Merge-Konflikte systematisch angeht, verliert weder Zeit noch Nerven – und schützt nebenbei die Codequalität.
Warum Git überhaupt Konflikte meldet
Git kann Änderungen normalerweise automatisch kombinieren. Ein Konflikt entsteht, wenn Git nicht eindeutig bestimmen kann, welche Variante „richtig“ ist. Das passiert vor allem dann, wenn zwei Branches denselben Bereich einer Datei verändern oder wenn eine Änderung die Grundlage der anderen verschiebt (zum Beispiel durch Umbenennungen).
Typische Auslöser im Alltag
- Zwei Personen ändern die gleiche Funktion oder die gleichen Zeilen in einer Datei.
- Eine Person formatiert großflächig (z. B. Prettier), während eine andere Logik in denselben Dateien ändert.
- Eine Datei wird verschoben/umbenannt, während sie parallel in einem anderen Branch bearbeitet wird.
- Ein Feature-Branch hängt lange hinter dem Hauptbranch hinterher (viele Überschneidungen).
Wichtig: Ein Konflikt ist keine „Fehlermeldung“ im klassischen Sinn. Er bedeutet: Git braucht eine Entscheidung – und diese Entscheidung muss aus fachlicher Sicht getroffen werden (Logik, Business-Regeln, Tests), nicht aus Bauchgefühl.
Konfliktanzeichen erkennen: Terminal, IDE und Git-Status
Meist beginnt es mit einem Merge oder Rebase, zum Beispiel:
git merge main (während man im Feature-Branch steht) oder ein Pull, der intern einen Merge auslöst.
Wenn ein Konflikt auftritt, zeigen Terminal und git status recht klar, welche Dateien betroffen sind. Git markiert Dateien als „unmerged“ und stoppt den Vorgang, bis die Konflikte aufgelöst sind.
Wie Konfliktmarker in Dateien aussehen
In der Datei tauchen Marker auf, die so aufgebaut sind:
- Bereich A (deine Version / aktueller Branch)
- Trennlinie
- Bereich B (eingehende Version / anderer Branch)
Diese Marker sind nur ein Arbeitszustand. Sie dürfen niemals im finalen Commit landen. Wenn sie doch im Repo auftauchen, wurde ein Konflikt „halb“ gelöst.
Konflikte sicher lösen: ein Vorgehen, das in Teams funktioniert
Beim Auflösen zählt weniger „Tempo“, sondern Kontrolle. Ein sauberer Ablauf reduziert Fehler drastisch.
Vorbereitung: kurz stoppen und Kontext sammeln
Bevor Änderungen geklickt werden: klären, was überhaupt zusammengeführt wird. Hilfreiche Fragen:
- Welche Änderungen kamen aus dem anderen Branch dazu?
- Welche Absicht steckt hinter den eigenen Änderungen?
- Gibt es Abhängigkeiten (z. B. neue Felder, neue API-Responses, geänderte Funktionssignaturen)?
Gerade bei Logik-Konflikten lohnt sich ein Blick auf den Commit-Verlauf oder den Pull-Request. In vielen Teams ist ein guter Startpunkt auch ein strukturierter Review-Prozess; passend dazu: Code Reviews im Team – Pull Requests besser machen.
Entscheiden: welche Variante bleibt – oder wie wird kombiniert?
Beim Lösen gibt es praktisch drei Optionen:
- Take ours: die eigene Version bleibt (sinnvoll, wenn der andere Branch veraltet ist oder die Änderung dort zurückgenommen werden soll).
- Take theirs: die eingehende Version gewinnt (sinnvoll, wenn sie die neue Wahrheit ist, z. B. nach Refactoring im Hauptbranch).
- Kombinieren: beide Änderungen werden zusammengeführt (am häufigsten, aber braucht am meisten Aufmerksamkeit).
„Kombinieren“ bedeutet nicht, beide Blöcke einfach hintereinander zu setzen. Es bedeutet, eine konsistente Endversion zu bauen: Namen, Parameter, Rückgabewerte und Seiteneffekte müssen zusammenpassen.
Praktische Schritte in einer kleinen So-geht’s-Box
- Merge/Rebase starten und Konfliktliste notieren (aus Terminal oder IDE).
- Pro Datei den Konfliktbereich verstehen: Was wollte jede Seite erreichen?
- Konfliktmarker entfernen und eine fachlich korrekte Endversion schreiben.
- Datei speichern und erneut prüfen, ob weitere Marker existieren (Suche nach <<<<<<< und >>>>>>>).
- Gelöste Dateien stagen: git add …
- Merge/Rebase fortsetzen (je nach Vorgang) und danach Tests ausführen.
Knifflige Fälle: Umbenennungen, Formatierungen und große Refactorings
Viele Konflikte sind nicht „inhaltlich“, sondern entstehen durch Strukturänderungen. Wer diese Muster erkennt, löst sie deutlich schneller.
Datei wurde verschoben oder umbenannt
Wenn eine Datei im einen Branch umbenannt wurde und im anderen Branch Änderungen am alten Pfad liegen, muss Git die Beziehung erst verstehen. In der Praxis hilft oft:
- prüfen, welche Datei die „neue Heimat“ ist,
- Änderungen aus dem alten Pfad in die neue Datei übertragen,
- darauf achten, dass Imports/Referenzen aktualisiert sind.
Danach unbedingt lokal bauen oder Tests starten, weil solche Konflikte gern „kompilieren“, aber zur Laufzeit knallen (z. B. falsche Importpfade).
Formatter-Konflikte (Prettier & Co.)
Wenn ein Branch nur formatierte Dateien enthält, erzeugt das auf den ersten Blick „riesige“ Konflikte. Der Trick ist, den Konflikt logisch zu reduzieren:
- erst Logik-Konflikte lösen (inhaltliche Änderungen),
- erst danach formatieren (einheitlicher Formatter-Lauf auf dem Endstand).
In Teams hilft eine klare Regel: Formatierung automatisch vor Commit/Push laufen lassen. Das lässt sich gut mit Git Hooks nutzen – Checks vor Commit und Push automatisieren absichern.
Refactoring trifft Feature-Entwicklung
Wenn im Hauptbranch eine Funktion umgebaut wurde und ein Feature-Branch noch die alte Version nutzt, entsteht oft ein Konflikt, der zwar „lösbar“ ist, aber neue Bugs einschleppt. Hier ist eine sichere Strategie:
- zuerst das Refactoring aus dem Hauptbranch vollständig übernehmen,
- dann die Feature-Änderungen auf die neue Struktur anpassen,
- gezielt Tests/Smoke-Checks für die betroffenen Bereiche ausführen.
Eine kleine Entscheidungshilfe: Merge oder Rebase bei Konflikten?
Beides kann Konflikte auslösen – der Unterschied liegt vor allem in der Historie und im Workflow:
| Ansatz | Wann passend | Worauf achten |
|---|---|---|
| Merge | Wenn die Branch-Historie sichtbar bleiben soll und mehrere Personen am Branch arbeiten. | Ein Merge-Commit ist normal; Konflikte werden einmalig an der Zusammenführung gelöst. |
| Rebase | Wenn ein Feature-Branch „sauber“ auf dem aktuellen Stand von main liegen soll. | Konflikte können in mehreren Schritten auftreten; nach dem Rebase ändert sich die Historie (Vorsicht bei geteilten Branches). |
Wer Rebase im Team nutzt, sollte die Regeln klar dokumentieren. Eine leicht verständliche Grundlage liefert: Git Rebase verstehen – Branches sauber zusammenführen.
Konflikte vorbeugen: kleine Gewohnheiten, große Wirkung
Konflikte lassen sich nicht komplett verhindern, aber deutlich reduzieren. Besonders wirksam sind Maßnahmen, die Branches klein halten und Überschneidungen minimieren.
Kompakte Liste für den Alltag im Team
- Branches kurzlebig halten: lieber mehrere kleine PRs als eine riesige.
- Regelmäßig vom Hauptbranch aktualisieren (z. B. täglich), statt wochenlang abzutauchen.
- Große Umformatierungen separat mergen, nicht zusammen mit Logik-Änderungen.
- Ownership absprechen: Wer arbeitet an welchen Dateien/Modulen?
- Konfliktträchtige Stellen entkoppeln (z. B. Konfigurationen aufteilen, Funktionen kürzen).
Wenn Konflikte ständig auftreten: Ursachen prüfen
Häufen sich Konflikte, liegt es oft an der Arbeitsweise, nicht am Tool. Häufige Ursachen sind:
- zu große Pull-Requests,
- unklare Modulgrenzen (alle ändern dieselben Dateien),
- fehlende Konventionen für Formatierung und Imports,
- lange lebende Feature-Branches ohne Zwischenintegration.
Gerade beim Thema Team-Workflow hilft ein sauberer Branching-Ansatz. Dazu passt: Git Branching verstehen – Workflow für Teams ohne Chaos.
Häufige Fehler beim Auflösen und wie sie sich vermeiden lassen
Viele Merge-Bugs kommen nicht vom Konflikt selbst, sondern vom „danach“.
Marker versehentlich committed
Wenn Konfliktmarker im Code bleiben, ist der Build oft sofort kaputt – manchmal aber nicht (z. B. in selten ausgeführten Dateien). Eine schnelle Kontrolle ist die Suche nach den Markern in den betroffenen Dateien, bevor committet wird.
„Beide Seiten behalten“ ohne Logik-Check
Gerade bei JSON-Konfigurationen, Routing-Tabellen oder Switch-Statements entsteht schnell doppelter Code oder widersprüchliche Reihenfolge. Hier hilft ein einfacher Grundsatz: nach dem Zusammenführen einmal bewusst die Datei „von oben nach unten“ lesen, als wäre sie neu.
Nur lokal gelöst, aber nicht getestet
Konflikte betreffen oft zentrale Stellen. Mindestens ein lokaler Testlauf oder ein schneller Smoke-Test ist Pflicht. In CI/CD-Pipelines fallen solche Fehler zwar auf, aber dann kostet es wieder eine Runde. Wer Deployments ohnehin automatisiert, profitiert davon, wenn Checks früh greifen; siehe: CI/CD Pipeline verstehen – Deployments sicher automatisieren.
Wenn gar nichts mehr geht: Konflikt-Abbruch und Neustart
Manchmal ist ein Konflikt so verworren, dass ein Neustart schneller und sicherer ist. Dann hilft es, den aktuellen Merge/Rebase sauber abzubrechen (je nach Vorgang) und mit einer frischen Strategie neu zu starten – zum Beispiel erst den Hauptbranch aktualisieren, dann die eigenen Commits schrittweise wieder anwenden. Wichtig ist: erst verstehen, was schief lief (lange Branch-Laufzeit, massive Refactorings, fehlende Absprachen), damit es nicht direkt wieder passiert.
