Conflict resolution

Conflict resolution is semantic work — not just choosing `ours` or `theirs`. Understand both branches' intent, resolve textual markers, check interactions, regenerate source-of-truth artifacts, and verify with tests.

					git merge origin/main
# edit conflicted files, remove <<<<<<< markers
git add path/to/file.ts
git commit
				

| Conflict type | Typical approach | |---------------|------------------| | Source code | Merge logic from both intents | | Lockfile | Regenerate with package manager | | Generated code | Re-run generator, do not hand-edit | | Renames | Use `git mv` history tools, verify imports |

On interviews: lockfile conflicts, concurrent API changes, when to pair with the other author, and merge vs rebase conflict differences.

Common pitfalls: accepting one side blindly; hand-editing `package-lock.json`; resolving conflicts without running tests.

The trade-off is speed (take one side) versus correctness (reconstruct combined intent).

Checklist:

• Identify both branches' goals before editing.
• Regenerate lockfiles and codegen outputs.
• Run focused tests after resolution.
• Escalate unclear semantic overlap to authors.