Git-Konflikte mit Claude Code sicher lösen

Einen Git-Konflikt zu lösen bedeutet nicht nur, <<<<<<<, ======= und >>>>>>> zu entfernen. Diese Marker zeigen nur, wo Git keine automatische Entscheidung treffen konnte. Die eigentliche Arbeit ist, die Absicht beider Branches zu bewahren: Eine Seite kann eine Sicherheitsprüfung verschärft haben, während die andere Seite eine neue UI, einen API-Aufruf und Tests ergänzt hat.

Claude Code ist dafür nützlich, weil es Konfliktdateien lesen, benachbarten Code prüfen, Git-Kommandos ausführen, Tests anpassen und den finalen Diff erklären kann. Trotzdem sollte es nicht allein entscheiden. Ein unklarer Auftrag wie “fix all conflicts” kann Code erzeugen, der kompiliert, aber eine Geschäftsregel verliert oder eine Prüfung doppelt ausführt.

Der stabile Ansatz lautet: Der Mensch definiert Priorität und Umfang, Claude Code erledigt die mechanische Bearbeitung, und der Mensch prüft Diff, Tests und Verhalten. Genau diesen Ablauf verwende ich in ClaudeCodeLab-Projekten.

Ablauf

Änderungen aus main oder release
        |
        v
Git meldet nicht zusammengeführte Dateien
        |
        v
Claude Code löst mit geschriebener Policy
        |
        v
Mensch prüft Diff, Tests und Verhalten
        |
        v
gelösten Zustand committen

Für nicht interaktive Aufrufe beschreibt die offizielle Claude Code CLI reference das Muster claude -p "query". Automatisierte Prüfungen basieren auf Claude Code hooks reference und Claude Code settings. Auf Git-Seite dokumentiert Git rerere, wie frühere Konfliktlösungen wiederverwendet werden.

Zustand zuerst prüfen

Bevor Claude Code Dateien ändert, sollte klar sein, was im Arbeitsbaum liegt.

git status --short
git branch --show-current
git diff --name-only --diff-filter=U

Der letzte Befehl zeigt nur ungelöste Dateien. Lies diese Liste selbst. Wenn dort eine unerwartete Datei steht, kläre zuerst, warum sie Teil des Konflikts ist.

Gib Claude Code vier Informationen:

Frage	Beispielregel
Welche Seite hat Priorität?	Sicherheitsfixes aus main behalten, Feature-UI ebenfalls behalten
Was darf editiert werden?	Nur ungelöste Dateien und direkt betroffene Tests
Wie mit generierten Dateien umgehen?	Lockfiles und generierten Code neu erzeugen statt manuell mergen
Wann ist es fertig?	Keine Marker, git diff --check sauber, Tests grün, Entscheidungen erklärt

Diese kurze Policy macht aus einer geratenen Lösung einen überprüfbaren Plan.

Fall 1: main in einen Feature-Branch mergen

Der häufigste Fall ist ein Feature-Branch, der vor dem Pull Request aktuelle Änderungen aus main aufnehmen muss.

git fetch origin
git merge origin/main

cat > /tmp/claude-conflict-plan.md <<'PROMPT'
Löse die aktuellen Git merge conflicts.

Kontext:
- Der aktuelle Branch ist ein Feature-Branch.
- Behalte Sicherheitsfixes und Typänderungen aus origin/main.
- Behalte den neuen Screen, den API-Aufruf und die Tests aus dem Feature.
- Bearbeite nur Dateien aus git diff --name-only --diff-filter=U.

Aufgaben:
1. Erkläre kurz, warum jede Datei kollidiert.
2. Entferne conflict markers und integriere beide Absichten.
3. Aktualisiere nur direkt betroffene Tests, falls nötig.
4. Führe git diff --check aus.
5. Fasse Entscheidungen und ausgeführte Befehle zusammen.

Nicht tun:
- Keine unabhängigen Refactorings.
- Keine Seite stillschweigend verwerfen.
- package-lock.json nicht manuell editieren.
PROMPT

claude -p "$(cat /tmp/claude-conflict-plan.md)"
git diff --check
npm test

Wichtig ist nicht die perfekte Formulierung, sondern die klare Grenze. Priorität, erlaubte Dateien, Regeln für generierte Dateien und Fertigkriterien machen das Ergebnis reviewbar.

Ein echter Fehler aus der Praxis: main enthielt eine strengere Autorisierung, der Feature-Branch eine neue UI-Verzweigung. Mit “behalte beides” blieb die UI sichtbar, aber die API gab weiter 403 zurück. Seitdem schreibe ich ausdrücklich, dass Sicherheits- und Autorisierungsänderungen erhalten bleiben und UI/API-Konsistenz geprüft wird.

Fall 2: Rebase Schritt für Schritt

Konflikte während git rebase sind heikler als normale Merge-Konflikte. Git hält bei jedem Commit an, und ours / theirs wirken im Rebase leicht kontraintuitiv. Nutze daher kein git checkout --ours, ohne den Diff zu verstehen.

git rebase origin/main

cat > /tmp/claude-rebase-step.md <<'PROMPT'
Löse nur den aktuellen Konflikt in diesem Rebase.

Zuerst:
- Bestätige mit git status, dass ein Rebase läuft.
- Liste ungelöste Dateien mit git diff --name-only --diff-filter=U.
- Leite die Absicht des gerade wiedergegebenen Commits aus dem aktuellen git log ab.
- Integriere diese Absicht mit dem aktuellen Verhalten von main.

Einschränkungen:
- git rebase --continue nicht ausführen.
- Nach Lösung und git add stoppen.
- Keine unabhängigen Dateien ändern.
- Bei Unsicherheit Optionen erklären, nicht raten.
PROMPT

claude -p "$(cat /tmp/claude-rebase-step.md)"
git diff --check
npm test
git rebase --continue

Automatisches Fortsetzen ist möglich, aber gerade am Anfang ist der Stopp pro Schritt sicherer. Wenn eine schlechte Lösung erst nach mehreren Commits auffällt, ist die Ursache deutlich schwerer zu finden.

Fall 3: Lockfiles und generierter Code

package-lock.json, pnpm-lock.yaml, OpenAPI-generierter Code, Prisma-Generierung und große Snapshots sind schlechte Kandidaten für manuelles Mergen. Löse zuerst die Quelle und erzeuge dann neu.

cat > /tmp/claude-lockfile-policy.md <<'PROMPT'
Löse Konflikte in Lockfiles oder generierten Dateien.

Policy:
- Zuerst menschlich gepflegte Quellen wie package.json, Schema oder OpenAPI lösen.
- package-lock.json nicht von Hand mergen.
- Wenn Dependencies entschieden sind, mit npm install neu erzeugen.
- Generierten Code aus der gelösten Quelle neu erzeugen.
- Erklären, warum der neu erzeugte Diff erwartet ist.

Erlaubte Befehle:
- npm install
- npm test
- npm run lint
PROMPT

claude -p "$(cat /tmp/claude-lockfile-policy.md)"
npm install
npm test
git add package.json package-lock.json

Der typische Fehler: package.json enthält beide neuen Dependencies, aber das Lockfile stammt nur von einer Seite. Lokal kann das funktionieren, in CI aber anders aufgelöst werden. Die Regel muss lauten: Quelle zuerst, generierte Ausgabe danach.

Fall 4: Ursache analysieren

Nach der Lösung lohnt sich eine kurze Retrospektive. Wenn Routen, Berechtigungen, Schemas oder Dependencies ständig kollidieren, ist meist der Ownership-Bereich zu groß oder der PR zu breit.

cat > /tmp/claude-conflict-retro.md <<'PROMPT'
Analysiere, warum dieser Git conflict entstanden ist.

Prüfe:
- Dateien mit git diff --name-only --diff-filter=U listen.
- Mit git log --oneline --all -- <file> beide Branch-Verläufe ansehen.
- Ursache klassifizieren: geteilte Ownership, zu großer PR, generierter Lärm, fehlende Regel.

Ausgabe:
- Ursache in drei Zeilen.
- Regeln für CLAUDE.md.
- Empfehlung: PR teilen, Owner abstimmen oder Tests ergänzen.
PROMPT

claude -p "$(cat /tmp/claude-conflict-retro.md)"

Wenn src/routes.ts jede Woche kollidiert, sollte die Routenregistrierung vielleicht pro Feature getrennt werden. Wenn package.json ständig betroffen ist, helfen separate Dependency-PRs.

Prüfungen und Teamregeln

Nach der Bearbeitung sollten mindestens diese Checks laufen:

git diff --check
git diff --name-only --diff-filter=U
npm test

Bei Verträgen, Routing, Billing oder Autorisierung kommen typecheck, lint und E2E hinzu. Wiederkehrende Checks kannst du mit hooks automatisieren. Siehe dazu den Claude Code Hooks Leitfaden.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Bash(git merge*)|Bash(git rebase*)",
        "hooks": [
          {
            "type": "command",
            "command": "git diff --check && npm test"
          }
        ]
      }
    ]
  }
}

Schreibe die Policy außerdem in CLAUDE.md, damit Claude Code sie als Projektgedächtnis nutzen kann. Mehr Struktur bieten CLAUDE.md best practices und der Team Collaboration Guide.

## Git conflict policy
- Sicherheitsfixes, Autorisierung und Schutz vor Datenverlust standardmäßig behalten.
- UI, API, Schema und Tests gemeinsam prüfen.
- Lockfiles und generierten Code neu erzeugen statt manuell editieren.
- Während Rebase prüft ein Mensch den Diff vor git rebase --continue.
- Bei unklarer Entscheidung Optionen präsentieren, keine Seite still verwerfen.

Fallstricke und Ergebnis

Merke dir ours und theirs nicht als feste Labels; im Rebase können sie überraschen. “Beides behalten” ist ebenfalls nicht immer richtig: Zwei Validierungen oder zwei Redirects können doppeltes Verhalten erzeugen. Und grüne Tests ersetzen keine fachliche Prüfung bei Authentifizierung, Zahlungen, Migrationen oder Löschlogik.

In einem TypeScript-Projekt mit rund 15 Konfliktdateien korrigierte ein vager Prompt die Syntax, vergaß aber einen passenden Test. Mit der Policy aus diesem Artikel erzeugte Claude Code einen kleineren Diff, erklärte Entscheidungen und verkürzte das Review.

Starte mit einem kleinen Feature-Branch: ungelöste Dateien listen, klare Policy geben, Tests ausführen, Diff prüfen. Wenn der Ablauf stabil ist, verschiebe wiederkehrende Regeln in hooks und CLAUDE.md, damit Konfliktlösung ein reproduzierbarer Teamprozess wird.