How do you resolve a merge conflict? Walk through the steps.

A merge conflict means Git cannot combine two sets of changes automatically, usually because both branches changed the same lines, or one branch deleted or renamed a file that the other modified. Git pauses, marks the conflicting sections, and waits for a human to decide what the result should be. The steps are: see what conflicted, understand both changes, edit to the correct combined result, verify, then mark resolved and continue.

Step by step

git merge main          # or: git rebase main, git cherry-pick <sha>, git pull
# CONFLICT (content): Merge conflict in tests/checkout.spec.ts

git status              # lists "both modified" (unmerged) files

Open each file. Git inserts markers:

<<<<<<< HEAD
await expect(page.getByRole('heading', { name: 'Order confirmed' })).toBeVisible();
=======
await expect(page.getByTestId('confirmation-title')).toHaveText('Thank you for your order');
>>>>>>> main

• Between <<<<<<< HEAD and =======: your current branch’s version.
• Between ======= and >>>>>>> main: the incoming version.

During a rebase the labels are reversed in meaning: HEAD is the branch you are rebasing onto, and the other side is your commit being replayed. This confuses many people, so read the labels rather than assuming.

Resolve deliberately

Decide what the code should be, which is often neither side as-is. In the example, maybe main changed the confirmation text and I changed the locator strategy, so the right result combines both:

await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();

If I do not understand the other change, I ask its author. Picking “mine” blindly is how fixes get silently reverted.

Helpful options:

git diff                         # shows conflicts in combined format
git checkout --ours   path/file  # take our side entirely (only when that's truly correct)
git checkout --theirs path/file  # take their side entirely
git mergetool                    # use a configured visual merge tool
git config --global merge.conflictStyle zdiff3   # also shows the common ancestor version

zdiff3 (Git 2.35+) shows what the code looked like before either change, which makes intent much clearer.

Verify, then continue

# make sure no markers remain
git diff --check
# run the relevant tests / lint / type-check
npx playwright test tests/checkout.spec.ts
git add tests/checkout.spec.ts
git merge --continue        # or: git rebase --continue / git commit

If it goes wrong, back out completely:

git merge --abort           # or: git rebase --abort

Reducing conflicts

• Integrate often: small, short-lived branches and frequent rebases or merges from main.
• Keep pull requests focused; avoid mixing formatting changes with logic changes.
• Agree on a formatter (Prettier, Black) so whitespace does not create conflicts.
• In test suites, shared files like a central locator map or a giant fixture file become conflict hotspots; splitting them by feature helps.

What interviewers look for

• Understanding why conflicts occur.
• Reading conflict markers correctly, including the rebase reversal.
• Resolving by intent, and talking to the other author when unsure.
• Running tests before continuing, and knowing --abort.