Konflikte lösen

Git-Konflikte lösen

Früher oder später passiert es jedem: Merge-Konflikt. Zwei Branches haben dieselbe Stelle einer Datei geändert, Git kann nicht entscheiden welche Variante gewinnt – du musst es ihm sagen. Anfänger empfinden Konflikte oft als beängstigend. In dieser Lektion lernst du, sie souverän zu lösen.

Wichtig: Konflikte sind nicht Bugs. Sie sind ein Sicherheitsmechanismus – Git fragt nach, statt blind eine Variante zu wählen. Wer das System versteht, fürchtet sich nicht mehr.

1) Wann entsteht ein Konflikt?

Ein Konflikt tritt auf, wenn Git nicht automatisch entscheiden kann, wie zwei Änderungen kombiniert werden. Typische Auslöser:

Du und ein Kollege ändert dieselbe Zeile einer Datei verschieden.
Du löschst eine Datei, ein Kollege ändert sie.
Beim git pull stehen lokale Änderungen quer zu Remote-Änderungen.
Beim git merge oder git rebase kollidieren Branches.

Was Git automatisch löst: Änderungen in verschiedenen Dateien, Änderungen in verschiedenen Zeilen derselben Datei. Nur direkte Überschneidungen brauchen menschliche Entscheidung.

2) Wie sieht ein Konflikt aus?

Wenn ein Konflikt auftritt, fügt Git spezielle Markierungen in die betroffene Datei ein. So sieht das aus:

Beispiel: Konflikt in einer Datei

// readme.md # Unser Projekt <<<<<<< HEAD Dieses Projekt verwendet TypeScript und React. Wir setzen auf moderne Tools wie Vite und Vitest. ======= Unser Projekt nutzt JavaScript mit dem React-Framework. Build-Tool ist Webpack, Tests laufen mit Jest. >>>>>>> feature/dokumentation Mehr unter docs.firma.de.

Drei Marker definieren den Konflikt: <<<<<<< HEAD beginnt deine Version (was im aktuellen Branch ist), ======= trennt die Versionen, >>>>>>> feature/dokumentation beendet die andere Version. Deine Aufgabe: entscheide, welche Version gilt – oder kombiniere beide. Dann lösche die Marker.

3) Auflösung Schritt für Schritt

So löst du einen Konflikt

Konflikt erkennen: nach git merge/git rebase/git pull zeigt Git „CONFLICT (content)". git status zeigt, welche Dateien betroffen sind.

Datei öffnen: betroffene Datei im Editor oder in der IDE öffnen. Die Marker <<<, ===, >>> finden.

Entscheidung treffen: drei Optionen pro Konflikt: nur HEAD, nur andere Version, beide kombiniert. Manchmal muss Code neu geschrieben werden.

Marker entfernen: alle <<<, ===, >>> raus. Datei muss am Ende sauber sein, ohne Spuren des Konflikts.

Datei zum Staging hinzufügen: git add <datei> – signalisiert Git: „Konflikt gelöst".

Merge abschließen: git commit (bei Merge) oder git rebase --continue (bei Rebase). Git öffnet vorgefertigte Commit-Nachricht.

Testen! Niemals nach Konflikt-Lösung direkt pushen. Erst testen, dass nichts kaputt ist.

Mit IDE-Hilfe wird das viel angenehmer: VS Code, IntelliJ und PyCharm haben grafische Konflikt-Editoren mit „Accept current", „Accept incoming", „Accept both" Buttons. Niemand muss heute mehr Marker manuell löschen – aber das Verständnis dafür ist wichtig.

4) Vorher vs. Nachher

Hier dasselbe Beispiel: Konflikt-Zustand und nach der Lösung. Klick zwischen den Tabs:

Beispiel-Lösung

Es gibt keine „richtige" Lösung – das hängt vom Inhalt ab. Manchmal will man die HEAD-Version, manchmal die andere, oft eine sinnvolle Kombination. Wichtig: Marker müssen vollständig entfernt sein, sonst hast du einen Syntax-Fehler im Code committet.

5) Befehle für Konflikte

Wichtige Konflikt-Befehle

# Status anzeigen – zeigt konfliktbehaftete Dateien
git status

# Konfliktbehaftete Dateien filtern
git diff --name-only --diff-filter=U

# Detail-Diff eines Konflikts
git diff <datei>

# Konflikt als "gelöst" markieren
git add <datei>

# Bei Merge: nach Lösung
git commit          # öffnet Default-Commit-Message

# Bei Rebase: nach Lösung
git rebase --continue

# Notfall: alles abbrechen
git merge --abort      # Merge rückgängig
git rebase --abort     # Rebase rückgängig

# Variante einer Seite komplett übernehmen
git checkout --ours <datei>     # eigene Version
git checkout --theirs <datei>   # andere Version

Die Notfall-Befehle --abort sind Goldwert: wenn du beim Konflikt-Lösen die Übersicht verlierst, kannst du jederzeit zurück zum Stand vor dem Merge/Rebase. Nichts ist verloren. --ours und --theirs sind beim Mergen Abkürzungen, wenn klar ist, welche Seite gewinnen soll.

6) Tool-Unterstützung

Manuelle Konflikt-Lösung ist mühsam. Heute nutzen die meisten Entwickler:innen grafische Tools:

VS Code: zeigt Konflikte mit Inline-Buttons „Accept Current", „Accept Incoming", „Accept Both", „Compare Changes". Sehr komfortabel.
IntelliJ / PyCharm: hat einen 3-Wege-Merge-Editor – links deine Version, rechts die andere, Mitte das Ergebnis.
Meld / kdiff3 / Beyond Compare: externe Merge-Tools, in git mergetool einbindbar.
GitLens (VS Code): zusätzliche Konflikt-Insights, Git-Blame inline.

Setup: git config --global merge.tool vscode + git mergetool startet das konfigurierte Tool. In der Praxis öffnen die meisten ihre IDE direkt – auch das funktioniert problemlos.

7) Konflikte vermeiden – Best Practices

Wie du Konflikte reduzierst

✓ Klein und früh committen

Kleine Branches mit kurzer Lebenszeit haben weniger Konflikt-Risiko als langlebige Branches.

✓ Häufig syncen

Täglich git pull origin main oder git rebase main – Konflikte früh erkennen.

✓ Klare Verantwortlichkeiten

Wer arbeitet an welchen Dateien? Bei klarer Trennung weniger Überschneidungen.

✓ Formatter im Team

Einheitliche Code-Formatierung (Prettier, Black) verhindert Whitespace-Konflikte.

✓ Modulare Architektur

Wenn jedes Team-Mitglied in eigenen Modulen arbeitet, gibt es weniger Überschneidungen.

✓ Kommunikation

Daily Stand-Up: „Ich arbeite heute an X" verhindert parallele Änderungen.

8) Anti-Muster bei Konflikten

Was du vermeiden solltest

✗ Marker drin lassen

Code mit <<<-Markern committen → Syntax-Fehler, Build kaputt.

✗ Blindes Akzeptieren

"Nehme einfach meine Version" → Kollegen-Arbeit verloren.

✗ Konflikte ignorieren

Mit --abort ständig wegrollen statt lösen → Branches divergieren immer mehr.

✗ Force-Push nach Konflikt

Lösung weg, Kollegen-Pull bringt Konflikt zurück. Lieber sauber lösen + committen.

✗ Nicht testen

Nach Konflikt-Lösung direkt pushen → meist ist was kaputt. Erst Tests, dann push.

✗ Alleine bleiben

Bei größeren Konflikten: Kollegen, der die andere Seite geschrieben hat, fragen.

9) Rebase-Konflikte sind anders

Bei Rebase entstehen Konflikte pro Commit, nicht einmal für das Ganze. Wenn du 5 Commits rebasest, kann jeder einzeln einen Konflikt produzieren. Workflow:

Konflikt im ersten Commit lösen → git add → git rebase --continue
Konflikt im zweiten Commit lösen → git add → git rebase --continue
... usw. bis fertig.

Bei vielen Konflikten kann das ermüdend sein. Tipp: lieber abbrechen (git rebase --abort) und stattdessen mergen. Oder: git rerere aktivieren – Git merkt sich gelöste Konflikte und wendet sie automatisch an, wenn sie wieder auftauchen.

10) Klausur-Fakten

Konflikt-Marker: <<<<<<<, =======, >>>>>>>
HEAD = aktuelle Branch-Version, nach dem === = andere Branch-Version.
Nach Lösung: git add <datei> markiert als gelöst.
Abschließen: git commit (Merge) oder git rebase --continue (Rebase).
Notfall: git merge --abort oder git rebase --abort.
Wann Konflikte entstehen: dieselben Zeilen, gleichzeitig geändert.

Zusammenfassung

Konflikte entstehen, wenn zwei Branches dieselbe Stelle anders ändern. Git markiert mit <<<<<<< HEAD, =======, >>>>>>> <branch>. Auflösung: entscheiden welche Variante (oder kombinieren) → Marker entfernen → git add → git commit (bei Merge) oder git rebase --continue (bei Rebase). Notfall: git merge --abort bzw. git rebase --abort. IDE-Tools (VS Code, IntelliJ) helfen massiv. Prävention: kleine Branches, oft syncen, klare Verantwortlichkeiten. Nächste Lektion: Git-Workflows.