# Git-Merge-Konflikte mit KI sicher lösen

URL: https://agentvera.dev/de/blog/resolve-merge-conflicts-with-ai/ · Veröffentlicht: 2026-10-29

Merge-Konflikte mit KI lösen, ohne Arbeit zu verlieren: zdiff3, ein Prompt für deinen Coding-Agenten, Tests vor git add, rerere, Rebase vs. Merge und Vorbeugung.

**Kurz gesagt:**

- Stell zuerst merge.conflictStyle auf zdiff3: Der Konflikt zeigt dann den gemeinsamen Vorfahren, und du und der Agent seht, was jede Seite wirklich geändert hat.
- Gib dem Agenten die Absicht beider Branches, die Konfliktdateien und klare Regeln: beide Änderungen behalten, nur Konfliktdateien anfassen, keine Marker übrig lassen, keine Tests passend machen.
- Prüfe vor git add: git diff --check für übrig gebliebene Marker, dann Typprüfung, Tests und Build, und zum Schluss liest du den gelösten Diff selbst.
- Die meisten Konflikte lassen sich vermeiden: kleine Aufgaben, ein Besitzer pro Dateibereich, häufiges Rebasen auf main und eine Merge-Queue, die jeden Branch auf dem neuesten Stand testet.

**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](/de/blog/merge-queue-for-ai-agents/ "Merge-Queue für KI-Agenten") zeigt ein Beispiel.

### Warum parallele Agenten Konflikte häufiger machen

Mehrere Agenten gleichzeitig, jeder in seinem eigenen [Git-Worktree](/de/glossary/git-worktree/ "Was ist ein 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:

```bash
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:

```bash
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:

```text
<<<<<<< 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`):

```bash
git config --global merge.conflictStyle zdiff3
```

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

```text
<<<<<<< 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:

```bash
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:

```bash
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:

```text
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:

```bash
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:

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

### Nie blind übernehmen: Warnzeichen in einer Lösung

| Warnzeichen | Was es meist bedeutet |
| --- | --- |
| Die Änderung einer Seite ist einfach weg | Der Agent hat eine Seite gewählt, statt beide zu kombinieren |
| Ein Test oder eine Assertion hat sich geändert | Die Lösung hat Verhalten kaputt gemacht und der Test wurde angepasst |
| Dateien außerhalb der Konfliktliste wurden geändert | Scope Creep: Umformatierungen oder „Fixes“, die ein eigenes Review brauchen |
| Code steht doppelt da | Beide Seiten wurden wörtlich behalten, nicht zusammengeführt |
| Marker oder ein verirrtes `=======` in einer Nicht-Code-Datei | Niemand hat `git diff --check` ausgeführt |

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.

| | Merge | Rebase |
| --- | --- | --- |
| Wo du löst | Einmal, im Merge-Commit | Commit für Commit, beim erneuten Anwenden |
| Derselbe Konflikt zweimal | Nein | Möglich, in mehreren Commits |
| `--ours` / `--theirs` | Dein Branch / der andere Branch | Vertauscht: das Ziel / deine eigene Arbeit |
| Historie | Behält einen Merge-Commit | Linear, schreibt die Commits des Branches neu |
| Sicher auf geteilten Branches | Ja | Nur wenn niemand auf diesem Branch aufbaut |

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:

```bash
git config --global rerere.enabled true
```

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

```bash
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:

```bash
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](/de/blog/git-worktree-parallel-agents/ "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](/de/features/agent-coordination/ "Agent-Koordination"); bei Agenten in verschiedenen Worktrees weist sie darauf hin, dass der Merge Konflikte haben kann.
- **Dateibesitz.** Mit [Dateibesitz](/de/features/file-ownership/ "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](/de/features/parallel-team/ "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](/de/features/merge-queue/ "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](/de/download/ "AgentVera herunterladen").

## Häufige Fragen

**Kann ein KI-Coding-Agent Git-Merge-Konflikte lösen?** Ja, und oft sogar gut, solange er den gemeinsamen Vorfahren sieht (zdiff3), weiß, was jeder Branch erreichen sollte, und eine Testsuite das Ergebnis belegt. Fehlt das, behält er gern eine Seite und lässt die andere stillschweigend fallen.

**Was ist der Konfliktstil zdiff3?** Ein Wert für merge.conflictStyle. Wie diff3 fügt er einen |||||||-Abschnitt mit dem Originaltext des gemeinsamen Vorfahren hinzu, schiebt aber Zeilen, die beide Seiten gleich geändert haben, aus dem Konfliktbereich. Git hat ihn mit Version 2.35 eingeführt.

**Warum sind ours und theirs beim Rebase 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. Schon deshalb ist ein pauschales --ours oder --theirs riskant.

**Was macht git rerere?** Mit rerere.enabled merkt sich Git, wie du einen Konflikt gelöst hast, und wendet diese Lösung erneut an, wenn derselbe Konflikt wieder auftaucht, etwa bei einem wiederholten Rebase. Den Index lässt es in Ruhe: Du prüfst das Ergebnis weiterhin und machst git add.

**Wie prüfe ich vor dem Merge, ob es Konflikte gibt?** Führe git merge-tree --write-tree --name-only main feature aus. Der Befehl führt den Merge durch, ohne Arbeitsverzeichnis oder Index anzufassen, endet bei Konflikten mit Exit-Code 1 und listet die betroffenen Dateien. Dafür brauchst du Git 2.38 oder neuer.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/