If you’ve ever pulled the latest changes, watched Git print CONFLICT (content): Merge conflict in, and felt your stomach drop — you’re not alone, and it’s not actually bad news.

A merge conflict means two branches changed the same part of a file, and Git isn’t willing to guess which version you want. That’s it. It’s not a sign you did something wrong; it’s Git asking a question only a human can answer.

What a conflict actually looks like

Open the flagged file and you’ll see something like this dropped right into your code:

<<<<<<< HEAD
const timeout = 3000;
=======
const timeout = 5000;
>>>>>>> feature/update-timeout

Three markers, three jobs:

  • <<<<<<< HEAD marks the start of your current branch’s version.
  • ======= is the dividing line between the two.
  • >>>>>>> feature/update-timeout marks the end of the incoming branch’s version.

Everything between the first two markers is what you have. Everything between the second two is what’s coming in. Your job is to replace the whole block — markers included — with whatever the correct final code should be.

The fix, step by step

  1. Run git status to see which files are conflicted. Work through them one at a time, not all at once.
  2. Open the file and read both versions carefully before touching anything.
  3. Decide the correct outcome. You’ve got three options: keep yours, keep theirs, or combine both into something new that reflects what actually needs to happen.
  4. Delete the conflict markers entirely. The file should read exactly as it should in production — no <<<<<<<, no =======, no >>>>>>> left behind anywhere.
  5. Stage it: git add filename.ext
  6. Finish the merge: git commit -m "Resolve merge conflict in filename.ext"

That’s the whole mechanical process. The part that actually takes judgment is step 3.

The two rules that matter most

Never guess. If you’re not sure which version is correct, a two-minute conversation with whoever wrote the other change is faster — and safer — than assuming and shipping the wrong one.

Never default to keeping your own version. It’s tempting when you’re in a hurry, but the incoming change might contain real work you’d be silently throwing away. Read both sides before you decide.

And always test after resolving — confirm the code still builds and runs correctly before you commit. A conflict resolved incorrectly is often worse than one left open, because a bad resolution can quietly discard someone’s work or introduce a bug nobody notices until much later.

The best conflict is the one you never have

A few habits go a long way: pull from main frequently while you’re on a feature branch, keep branches short-lived, and say something when you know you’re working in the same area of code as a teammate. git pull origin main run regularly keeps your branch close enough to main that conflicts, when they do happen, stay small.

If a conflict lands in code you didn’t write and don’t fully understand, that’s the moment to stop and ask, not guess. There’s no shame in “I’ve got a conflict in code I’m not familiar with — can you help me sort it out?” It’s a two-minute question that saves everyone a much worse afternoon.