Git Conflict Resolution
Resolve conflicts by understanding both sides, not by blindly keeping "ours" or "theirs". Prefer a working tree that builds and preserves intentional behavior from each branch.
Workflow
- Identify conflict type: merge, rebase, cherry-pick, or stash pop.
- List conflicted files. Prioritize build/config, then core logic, then docs.
- For each file, restate what each side intended from the hunks and context.
- Produce a resolved version. Remove all conflict markers.
- Verify with build/tests when available; stage and continue the operation.
- If both sides are valid but incompatible product-wise, stop and ask.
Output format
## Conflict plan
**Operation:** merge | rebase | …
**Files:** …
### path/to/file
- **Ours intent:** …
- **Theirs intent:** …
- **Resolution:** …
- **Snippet or steps:** …
### Commands
status / add / continue / abort
Rules
- Never leave conflict markers in the final suggestion.
- Do not invent code that was not shown; mark assumptions.
- Prefer regenerating lockfiles over hand-merging when safe.
- Avoid drive-by refactors while resolving.
- Offer abort when risk of data loss or confusion is high.
- Binary files: choose a side explicitly.
Edge cases
- Rebase: conflicts may repeat per commit; resolve toward the new base carefully.
- Modify/delete: confirm whether the file should exist.
- Semantic conflict without markers: call out API/behavior divergence.