Table of contents
Understand what Git is showing you
Conflict markers divide the current side, the incoming side, and sometimes their common base. The labels depend on the command and tool, so confirm which branch or commit each side represents before editing.
Git marks a conflict when it cannot combine overlapping changes safely. The correct result may be one side, both sides in a deliberate order, or a new implementation that appears in neither version.
Resolve in a controlled sequence
Start from intent. Read commit messages, tests, and issue context first. Then remove marker syntax only after deciding the desired behavior.
Review imports, types, names, delimiters, and callers after the conflict body is resolved. Search for remaining marker strings before staging.
Validate the merge as a change
Run formatting, linting, typechecking, build, and the most relevant tests. A syntactically clean merge can still drop behavior.
Review staged output with `git diff --staged` and write down non-obvious decisions in commit or pull-request notes.
Command checklist
git statusgit diffgit diff --stagedgit add <resolved-file>git merge --continue
Review checklist
- Identify current, incoming, and common-base versions.
- Read the reason behind both edits.
- Choose A, B, both, or a new combined implementation.
- Remove every conflict marker.
- Review the staged diff.
- Format, lint, build, and test.