Git-Merge-Konflikte mit KI sicher lösen

Um Merge-Konflikte mit KI sicher zu lösen, machst du den Konflikt zuerst lesbar, gibst dann einem Coding-Agenten die Absicht beider Seiten und klare Regeln und übernimmst das Ergebnis erst, wenn Git bestätigt, dass keine Konfliktmarker übrig sind, und deine Tests grün sind. Agenten wie Claude Code und Codex sind dabei wirklich nützlich: Sie lesen beide Versionen, den gemeinsamen Vorfahren und den Code drumherum schneller als du und können zwei Änderungen kombinieren, statt eine auszuwählen. Ihr typischer Fehler ist genauso klar: Wenn die Absicht einer Seite unklar ist, behalten sie die Seite, die kompiliert, und lassen die andere wortlos fallen.

Diese Anleitung erklärt, warum Konflikte entstehen (und warum parallele Agenten sie häufiger machen), einen Ablauf Schritt für Schritt von git status bis git merge --continue, eine Prompt-Vorlage, Rebase vs. Merge, git rerere, eine Prüfung vor dem Merge und wie du die meisten Konflikte von vornherein vermeidest. Die Git-Befehle sind mit der offiziellen Dokumentation auf git-scm.com abgeglichen, Stand Oktober 2026.

Warum Merge-Konflikte entstehen

Wenn Git zwei Branches zusammenführt, vergleicht es beide mit ihrem gemeinsamen Vorfahren. Änderungen an verschiedenen Stellen einer Datei werden automatisch kombiniert. Haben beide Seiten dieselbe Stelle geändert, kann Git keine wählen: Es hält an und schreibt beide Versionen zwischen Konfliktmarkern in die Datei. Das ist ein textueller Konflikt.

Die häufigsten Arten:

• Inhaltskonflikt: Beide Branches haben dieselben Zeilen derselben Datei geändert.
• Ändern/Löschen: Ein Branch hat eine Datei geändert, der andere hat sie gelöscht oder verschoben.
• Generierte Dateien: Lockfiles, Snapshots, Build-Ausgaben oder Übersetzungsbündel, die beide Branches neu erzeugt haben.

Es gibt noch einen Konflikt, den Git nicht sieht: den semantischen Konflikt. Zwei Branches ändern verschiedene Dateien, lassen sich sauber mergen und machen sich trotzdem gegenseitig kaputt, zum Beispiel wenn einer eine Funktionssignatur ändert und der andere einen neuen Aufruf hinzufügt. Das fangen nur Tests auf dem gemergten Ergebnis ab; der Beitrag zur Merge-Queue zeigt ein Beispiel.

Warum parallele Agenten Konflikte häufiger machen

Mehrere Agenten gleichzeitig, jeder in seinem eigenen Git-Worktree, überschreiben sich beim Arbeiten nicht gegenseitig die Dateien. Den Konflikt verhindert das nicht; es verschiebt ihn auf den Zeitpunkt des Merges. Jeder Agent arbeitet auf dem Stand, mit dem er gestartet ist, und sieht nicht, was die anderen ändern. Einige Dateien ziehen Konflikte immer wieder an:

• Routentabellen, Dependency-Injection-Setups und andere Registries, in die jedes Feature eine Zeile einträgt,
• Barrel-Dateien (index.ts) und gemeinsame Typen,
• package.json und die zugehörige Lockfile,
• Übersetzungsdateien, Changelogs und Konfigurationsdateien.

Auch die Gründlichkeit der Agenten schadet hier: Sie formatieren eine Datei komplett neu, die sie nur berühren sollten, benennen „bei der Gelegenheit“ eine Hilfsfunktion um oder beheben eine fremde Lint-Warnung. Jede dieser Änderungen vergrößert den Bereich, den beide Branches angefasst haben.

Schritt 1: anhalten und erst einmal schauen

Wenn ein Merge oder Rebase stoppt, finde heraus, wo du stehst, bevor du irgendwen, Mensch oder Agent, um eine Lösung bittest:

git status                                  # welche Operation, welche Dateien "both modified" sind
git diff --name-only --diff-filter=U        # nur die nicht gemergten Dateien

--diff-filter=U wählt nicht gemergte Pfade aus; so bekommst du eine saubere Liste, die du dem Agenten geben kannst. Denk auch an die Notausgänge. Ist der Konflikt größer als erwartet, ist noch nichts verloren:

git merge --abort      # zurück zum Zustand vor dem Merge
git rebase --abort     # zurück zum Stand des Branches vor dem Rebase

Die Git-Dokumentation empfiehlt, eigene Änderungen vor git merge zu committen oder zu stashen, weil --abort nicht committete Arbeit nicht immer wiederherstellen kann. Dasselbe gilt für den Worktree eines Agenten: Lass ihn committen, bevor du etwas hineinmergst.

Schritt 2: auf zdiff3 umstellen, damit die Basis sichtbar wird

Standardmäßig zeigt Git nur die beiden Seiten:

<<<<<<< HEAD
const timeout = config.timeout ?? 30_000;
=======
const timeout = getTimeout(config);
>>>>>>> feature/retry

Daran siehst du nicht, wie die Zeile ursprünglich aussah, also auch nicht, was jede Seite wollte. Stell den Konfliktstil auf zdiff3 (seit Git 2.35; bei älteren Versionen diff3):

git config --global merge.conflictStyle zdiff3

Jetzt enthält der Konflikt nach einem |||||||-Marker auch den gemeinsamen Vorfahren:

<<<<<<< HEAD
const timeout = config.timeout ?? 30_000;
||||||| base
const timeout = config.timeout;
=======
const timeout = getTimeout(config);
>>>>>>> feature/retry

Jetzt ist es lesbar: Eine Seite hat einen Standardwert ergänzt, die andere hat das Auslesen in eine Funktion verschoben. Die richtige Lösung behält vermutlich beides, etwa indem der Standardwert in getTimeout wandert. Laut git-config-Dokumentation ist zdiff3 wie diff3, schiebt aber übereinstimmende Zeilen am Anfang und Ende eines Konflikts aus dem Konfliktbereich, sodass die Hunks klein bleiben.

Bei einem laufenden Merge kannst du die Marker einer Datei im neuen Stil neu erzeugen:

git checkout --conflict=zdiff3 src/http/client.ts

Für einen Agenten ist das noch wichtiger als für dich. Ohne Basis muss das Modell raten, welche Seite was geändert hat, und genau beim Raten beginnt stiller Datenverlust.

Schritt 3: dem Agenten den nötigen Kontext geben

Die Konfliktmarker zeigen die Zeilen. Der Agent muss aber auch wissen, warum jede Seite sie geändert hat. Git kann die Historie beider Seiten für eine Datei zeigen:

git log --merge -p src/http/client.ts   # zuerst die Diffs der HEAD-Seite, dann die von MERGE_HEAD
git show :1:src/http/client.ts          # gemeinsamer Vorfahre
git show :2:src/http/client.ts          # HEAD (ours)
git show :3:src/http/client.ts          # MERGE_HEAD (theirs)

Dazu kommt der menschliche Kontext: die Aufgabe oder Pull-Request-Beschreibung jedes Branches. Dann nimm einen Prompt wie diesen:

Wir sind mitten in einem git merge von feature/retry in main. Diese Dateien
haben Konflikte (merge.conflictStyle ist zdiff3, die Basis ist sichtbar):
<Ausgabe von git diff --name-only --diff-filter=U>

Absicht von main: <ein, zwei Sätze oder die PR-Beschreibung>
Absicht von feature/retry: <ein, zwei Sätze oder die PR-Beschreibung>

Für jede Konfliktdatei:
1. Lies ours, base und theirs und sag in einer Zeile, was jede Seite
   gegenüber der Basis geändert hat.
2. Schreib eine Lösung, die beide Absichten erhält. Wenn sie sich wirklich
   widersprechen, entscheide nicht, sondern halte an und frag mich.
3. Bearbeite nur die Konflikt-Hunks. Kein Umformatieren, keine Umbenennungen,
   keine fremden Fixes.
4. Ändere keine Tests, damit sie grün werden, und lösch keinen Code,
   den du nicht verstehst.
Für package-lock.json / pnpm-lock.yaml: nur package.json lösen, dann die
Lockfile mit dem Paketmanager neu erzeugen.
Am Ende: keine Konfliktmarker mehr, Typprüfung und Tests ausführen und pro
Datei zusammenfassen, was du von welcher Seite behalten hast. Führe kein
git add, git commit oder git merge --continue aus.

Die letzte Zeile lässt den letzten Schritt bei dir. Die Zusammenfassung pro Datei beschleunigt das Review: Du vergleichst jede Aussage mit dem Diff, statt jede Zeile kalt zu lesen.

Schritt 4: Datei für Datei, nach klaren Regeln

Ein paar Regeln entscheiden zwischen einem sauberen Merge und einer stillen Regression:

• Kein pauschales --ours oder --theirs. git checkout --ours <pfad> nimmt eine ganze Seite der Datei und verwirft die andere. Nutz das nur, wenn du weißt, dass eine Seite gewinnen soll, etwa bei einer generierten Datei, die du ohnehin neu erzeugst.
• Vorsicht beim Rebase, die Seiten sind vertauscht. Laut Git-Dokumentation ist bei git rebase und git pull --rebase --ours der Branch, auf den du rebasest, und --theirs deine eigene Arbeit, die neu angewendet wird. Agenten verwechseln das erstaunlich oft, also nenn ihnen die Branches beim Namen.
• Generierte Dateien neu erzeugen, nicht mergen. Lockfiles, Snapshots und Build-Ausgaben sollen vom Werkzeug kommen, das sie erzeugt, nachdem die Quelldateien gelöst sind.
• Ändern/Löschen braucht eine Entscheidung. Hat ein Branch eine Datei gelöscht, die der andere geändert hat, soll der Agent das melden und fragen, statt sie eigenmächtig wiederherzustellen oder zu löschen.
• Große Konflikte aufteilen. Hat eine Datei Dutzende Hunks, lass den Agenten sie in Teilen lösen und erklären, oder tritt einen Schritt zurück und überdenke die Merge-Reihenfolge.

Schritt 5: prüfen, bevor es weitergeht

Wenn ein Agent „gelöst“ sagt, ist das eine Behauptung, kein Beweis. Prüfe sie:

git diff --check                 # warnt vor übrig gebliebenen Konfliktmarkern (und Whitespace-Fehlern)
git diff                         # die Lösung durchsehen
pnpm typecheck && pnpm test      # oder die Prüfung deines Projekts

git diff --check endet mit einem Fehlercode, wenn Änderungen Konfliktmarker enthalten, und ist damit eine billige Hürde für jedes Mal. In neueren Git-Versionen zeigt git diff AUTO_MERGE nur die Änderungen, die bisher zur Lösung der textuellen Konflikte gemacht wurden, also genau das, was der Agent geschrieben hat.

Den Vorgang schließt du selbst ab:

git add src/http/client.ts
git merge --continue     # oder: git rebase --continue

Nie blind übernehmen: Warnzeichen in einer Lösung

Siehst du eines davon, lass den Agenten den Hunk erklären oder löse die Datei von Hand neu. Ein KI-Code-Review des Merge-Ergebnisses ist ein nützliches zweites Augenpaar, ersetzt aber nicht das Ausführen der Tests.

Rebase oder Merge, wenn Konflikte wahrscheinlich sind

Beides funktioniert; sie scheitern unterschiedlich.

Für kurzlebige Agenten-Branches, die nur du nutzt, ist häufiges Rebasen auf main meist die einfachere Gewohnheit: Konflikte tauchen früh auf, solange sie klein sind. Für langlebige oder geteilte Branches merge. Während eines Rebase verwirft git rebase --skip den aktuellen Commit komplett; nutz es nur, wenn du sicher bist, dass dieser Commit nicht gebraucht wird.

Git merkt es sich: rerere

Wenn du denselben Branch immer wieder rebasest, löst du denselben Konflikt mehr als einmal. git rerere („reuse recorded resolution“) merkt sich, wie du einen Konflikt gelöst hast, und spielt das erneut ab, wenn derselbe Konflikt wieder auftritt:

git config --global rerere.enabled true

Einmal aktiviert, rufen git merge und git commit es automatisch auf. Nützliche Befehle:

git rerere status       # Pfade, deren Lösung aufgezeichnet wird
git rerere diff         # wie die aktuelle Lösung aussieht
git rerere remaining    # Konflikte, die rerere nicht lösen konnte
git rerere forget src/http/client.ts   # eine falsch aufgezeichnete Lösung verwerfen

Zwei Dinge solltest du wissen. rerere lässt den Index in Ruhe; du prüfst das Ergebnis weiterhin und machst git add. Das ist gut so, denn eine falsche Lösung wird genauso treu wiederholt wie eine richtige. Und alte Einträge räumt git rerere gc auf: standardmäßig ungelöste nach 15 Tagen und gelöste nach 60.

Konflikte vor dem Merge prüfen

Du musst einen Merge nicht starten, um zu erfahren, ob er Konflikte hat. Seit Git 2.38 führt git merge-tree --write-tree den Merge aus, ohne Arbeitsverzeichnis oder Index anzufassen:

git merge-tree --write-tree --name-only main feature/retry
echo $?    # 0 = sauber, 1 = Konflikte

Mit --name-only listet der Konfliktabschnitt nur die Dateinamen. Die Git-Dokumentation rät, sich auf den Exit-Code zu verlassen statt auf eine leere Dateiliste. Das ist ein praktischer erster Auftrag für einen Agenten, bevor er irgendetwas anfasst: „Prüf, ob feature/retry sauber in main mergt, und wenn nicht, liste die Konfliktdateien und was jede Seite geändert hat.“

Vorbeugen: weniger Konflikte mit parallelen Agenten

Der billigste Konflikt ist der, der nie entsteht:

• Kleine Aufgaben. Ein Agent, der fünf Dateien ändert, kollidiert seltener als einer, der fünfzig ändert. Teil große Aufgaben nach Bereichen auf.
• Ein Besitzer pro Bereich. Leg fest, welcher Agent den Router, das Schema, die gemeinsamen Typen ändern darf, und schreib es in die Anweisungen jedes Agenten.
• Oft mergen oder rebasen. Ein Branch, der eine Stunde lebt, hat selten Konflikte; einer, der eine Woche lebt, fast immer.
• Keine Änderungen im Vorbeigehen. Sag den Agenten, dass sie außerhalb ihrer Aufgabe nichts umformatieren, umbenennen oder reparieren.
• Immer nur eine Lockfile-Änderung. Lass nur einen Branch Abhängigkeiten hinzufügen oder erzeuge die Lockfile nach jedem Merge neu.
• Eine Merge-Queue. Branches landen einzeln auf dem neuesten Stand, mit Tests auf dem gemergten Ergebnis, sodass auch semantische Konflikte auffallen.

Wie du Agenten in getrennten Ordnern aufsetzt, steht in Git-Worktrees für parallele Agenten.

So hilft AgentVera

AgentVera ist eine Desktop-App, die Coding-Agent-CLIs wie Claude Code und Codex nebeneinander ausführt, mit eingebautem Git. Diese Funktionen greifen in den Ablauf oben ein:

• Worktrees und das Git-Panel. Leg pro Feature einen Worktree an und starte darin einen Agenten; stage pro Datei, committe, fetche, pulle und pushe und lies Diffs im GitHub-Stil, unified oder geteilt.
• Frühe Warnungen. Standardmäßig führt AgentVera alle 5 Minuten im Hintergrund git fetch aus. Kommen neue Commits auf deinem Branch an, bietet ein Banner einen Fast-Forward mit einem Klick an, oder einen Rebase, wenn beide Seiten Commits haben. Bearbeiten zwei Agenten im selben Projekt dieselbe Datei, warnt dich die Agent-Koordination; bei Agenten in verschiedenen Worktrees weist sie darauf hin, dass der Merge Konflikte haben kann.
• Dateibesitz. Mit Dateibesitz gibst du einem Agenten Pfade oder Globs wie src/api/**. Solange er läuft, werden Claude-Code-Agenten vor dem Bearbeiten dieser Dateien gestoppt und angewiesen, den Besitzer zu fragen; Codex und andere CLIs bekommen die Regeln in ihren Anweisungen.
• Paralleles Team. Ein paralleles Team (Pro) teilt eine Aufgabe in Teile, die jeweils in einem eigenen Worktree laufen und in einen Integrations-Branch gemergt werden. Kommt es beim Merge zu einem Konflikt oder schlägt die abschließende Prüfung fehl, springt ein Integrations-Agent ein.
• Merge-Queue. Die Merge-Queue (Pro) mergt Branches einzeln auf den neuesten Stand des Ziels. Ein Claude-Agent löst Konflikte, die Prüfung läuft auf dem gemergten Ergebnis mit bis zu 2 Fix-Runden, und ein Branch, der sich nicht reparieren lässt, wird zurückgegeben. Das Landen wartet standardmäßig auf deine Freigabe.

Wenn du allein und immer nur an einem Branch arbeitest, reicht schlichtes Git mit zdiff3 und rerere. Diese Werkzeuge lohnen sich, sobald mehrere Agenten gleichzeitig Branches erzeugen.

Häufige Fehler

• Ohne Basis lösen. Der Standard-Konfliktstil verbirgt, wie der Code vorher aussah; schalte zdiff3 ein.
• „Behebe die Konflikte“ als ganzer Prompt. Ohne die Absicht jedes Branches wählt der Agent die Seite, die vollständiger aussieht.
• Den Agenten git add und --continue ausführen lassen. Heb dir den letzten Schritt für nach git diff --check und den Tests auf.
• Lockfiles von Hand mergen. Löse das Manifest und erzeuge die Lockfile neu.
• Einen geteilten Branch rebasen. Alle, die darauf aufgebaut haben, müssen dann umgeschriebene Commits entwirren.

Fazit

Merge-Konflikte mit KI zu lösen funktioniert, wenn der Agent das ganze Bild sieht und der Beweis bei dir bleibt: zdiff3-Marker, die die Basis zeigen, ein Prompt, der beide Absichten nennt und Abkürzungen verbietet, git diff --check und die Testsuite vor git add und rerere für Konflikte, die immer wiederkommen. Den Rest erledigt die Vorbeugung: kleine Aufgaben, klarer Dateibesitz und Branches, die einzeln landen.

Um es mit deinen eigenen Agenten auszuprobieren, lade AgentVera herunter.