Git-Merge-Konflikt systematisch lösen

Aus einem Konflikt-Hunk eine Entscheidung - welche Seite, welche Teile beider, oder komplette Neuformulierung. Mit Commit-Intent-Check.

Zuletzt geprüft 23. April 2026

Prompt

I have a merge conflict. Help me resolve it systematically - not by guessing.

For each conflict hunk, produce:
1. WHAT EACH SIDE CHANGED - two sentences (ours vs theirs)
2. INTENT - what was each side trying to achieve (based on surrounding context and commit messages if given)
3. CONFLICT TYPE:
   - Textual-only (same region, different formatting) → easy merge
   - Semantic overlap (both modified same logic differently) → needs thought
   - Incompatible intent (one removes what other depends on) → design decision, not merge
4. RECOMMENDED RESOLUTION:
   - ours / theirs / combined / rewrite-from-intent
   - Show the merged snippet
   - State ONE assumption you made - so I can sanity-check

Rules:
- Never "just take both" without reasoning
- If you can't reconstruct intent from context, STOP and ask - do not guess
- Flag any hunk where the merge could hide a silent bug

Context:
- Branch being merged: [BRANCH]
- Purpose of that branch: [PURPOSE]
- Commits on each side (optional): [LOG SNIPPETS]

Conflict:
[PASTE CONFLICT HUNK(S)]

Wann nutzen

Bei größeren Merge-Konflikten, wo 'beides behalten' gefährlich ist. Der Intent-Check ist der Schutz gegen still einführte Bugs.

Use-Cases

  • Lang laufender Feature-Branch gegen main.
  • Refactor-Branch trifft auf Feature, der gleiche Datei geändert hat.
  • Conflict in generated code / locked file.

Getestet mit

Bei Konflikten in generierten Files (lockfiles, Schema-Dumps): das Modell neu generieren lassen, nicht mergen.