Resolving Git Merge Conflicts Without Panic

A conflict means Git found two changes to the same lines and won't guess which one you want. It's a normal part of teamwork, not an error.

1. See what's conflicted

git status
# both modified:   src/pricing.js

2. Read the markers

function shippingFee(total) {
<<<<<<< HEAD
  return total >= 500 ? 0 : 49;
=======
  return total >= 999 ? 0 : 59;
>>>>>>> feature/new-shipping-rates
}

• Between <<<<<<< and =======: your current branch's version.
• Between ======= and >>>>>>>: the incoming branch's version.

Turn on the three-way style to also see the common ancestor, which makes intent much clearer:

git config --global merge.conflictStyle zdiff3

3. Decide, edit, test

Sometimes you keep one side, sometimes you combine both. Understand what each change was trying to do (read the commit messages) before choosing. Remove all markers, then run the tests.

4. Mark resolved and continue

git add src/pricing.js
git merge --continue        # or: git rebase --continue

Escape hatches

git merge --abort                       # back to before the merge
git checkout --ours src/pricing.js      # take our version of this file
git checkout --theirs src/pricing.js    # take their version

During a rebase, "ours" and "theirs" are swapped: "ours" is the branch you're rebasing onto.

Prevent conflicts

• Merge or rebase from main often; small, frequent syncs mean small conflicts.
• Keep pull requests small and short-lived.
• Agree on formatting with an auto-formatter, so style changes don't collide.
• Enable git config --global rerere.enabled true so Git remembers how you resolved a conflict and reapplies it.