Git Conflict Resolution

---
name: git-conflict-resolution
description: Resolve merge and rebase conflicts deliberately. Use when a merge, rebase, cherry-pick, or pull stops with conflicts and the user wants them resolved safely.
---

# Git Conflict Resolution

A conflict is two intentions colliding. Resolve by understanding both, not by picking a side at random.

## Triage

1. `git status` — are we merging or rebasing? Which files conflict?
2. `git diff --name-only --diff-filter=U` for the conflict list.
3. For each file, read both versions of the conflicted region. Understand what each side was trying to accomplish before editing. Check the commits on each side: `git log --oneline main..HEAD` and the incoming branch.
4. Escape hatches exist — tell the user they can bail: `git merge --abort` / `git rebase --abort`.

## Resolving

- **Same area, different logic:** hand-merge. Keep both behaviors; the resolution is usually a synthesis, not a choice.
- **Both added similar code:** deduplicate into one version, keep the better name/structure.
- **One side moved/renamed, other side edited:** apply the edits to the moved location.
- **Lockfiles / generated files:** never hand-merge. Take either side, then regenerate: `npm install`, `pnpm install`, or the project's generator. Verify the lockfile parses.
- **When genuinely ambiguous:** stop and ask the user which behavior is correct. A wrong silent merge is worse than a question.

## After resolving each file

`git add <file>`, then continue: `git merge --continue` / `git rebase --continue`.

## Verify (mandatory)

1. Build and run the test suite — conflict resolution breaks code silently.
2. `git diff main...HEAD --stat` (or the merge result) — sanity-check the final change matches both intents.
3. During rebase: watch for the same conflict recurring on later commits; resolve consistently.