Resolve the intended behavior, not just the markers

First, build a mental model

A merge conflict means Git cannot choose a text result automatically. You supply the intended combined behavior. Removing markers and staging the file records your choice; neither action proves that the choice is correct.

1. Read the common base and both changes to identify each author's intent.
2. A conflict can need a combination, a redesign or one selected behavior; blindly accepting all ours or theirs can erase useful work.
3. After resolving, inspect the final file, stage it and use the continuation command for the operation in progress.
4. Run checks on the integrated result. A clean automatic merge can also combine semantically incompatible code.
5. Start integration from a controlled working tree. An abort is an escape from an in-progress operation, not a general guarantee to reconstruct unrelated uncommitted edits.

// Common base: retries = 1, timeoutMs = 2000.
// HEAD intentionally raises retries to 3.
// feature/timeouts intentionally raises timeoutMs to 5000.
<<<<<<< HEAD
const policy = { retries: 3, timeoutMs: 2000 };
=======
const policy = { retries: 1, timeoutMs: 5000 };
>>>>>>> feature/timeouts
// The markers shown above are a conflict fixture, not valid JavaScript.

1. Base

   The shared starting policy has one retry and a 2000 ms timeout.

2. Separate intents

   One branch changes retries; the other changes timeout.

3. Resolution

   If both requirements remain valid, the intended combined policy is retries 3 and timeoutMs 5000.