Resolving a merge conflict without panicking

Why conflicts happen

Most of the time git merges changes for you automatically — you and a teammate edited different files, or different parts of the same file, and git just combines them. A conflict only happens when two changes overlap on the same lines and git can't pick a winner on its own. That's it. It's not corruption, and nothing is lost; git has both versions safe and is pausing to let you choose.

You'll usually meet one during a git merge, a git pull (which merges), or sometimes a git stash pop or rebase. Git tells you plainly:

Auto-merging Program.cs
CONFLICT (content): Merge conflict in Program.cs
Automatic merge failed; fix conflicts and then commit the result.

Reading the markers

Open the conflicted file and you'll find a block like this where the overlap is:

<<<<<<< HEAD
var timeout = 30;
=======
var timeout = 60;
>>>>>>> feature/longer-timeout

Three markers, and they're simpler than they look:

• <<<<<<< HEAD — everything below this, up to the =======, is your side (the branch you're on).
• ======= — the divider between the two versions.
• >>>>>>> feature/longer-timeout — everything above this, down from the =======, is the incoming side (the branch being merged in).

So git is showing you both: your timeout = 30 and their timeout = 60, and asking which should win — or whether the right answer is some combination.

Resolving it

Resolving a conflict is just editing the file so it's correct, then removing the markers. There's no magic command that decides for you; you read both sides and write what the code should actually be. For the example above you might keep theirs:

var timeout = 60;

Delete the three marker lines and the version you don't want, leaving only the final, correct code. Do that for every conflict block in the file (there may be more than one), and for every conflicted file (git lists them, and git status always reminds you which are left).

The point to internalize: the answer isn't always "pick a side." Sometimes both changes belong and you combine them; sometimes neither is quite right and you write a third version. You're not choosing a winner mechanically — you're making the code correct.

Finishing the merge

Once a file looks right and the markers are gone, stage it to tell git "this one's resolved":

git add Program.cs

When git status shows nothing left unresolved, complete the merge with a commit:

git commit

Git pre-fills a merge commit message for you; you can usually accept it as-is. That's the whole loop: edit to resolve → git add each file → git commit. The conflict is over.

How to have fewer of them

You can't eliminate conflicts, but you can keep them small and rare:

• Pull often. The longer your branch drifts from main, the more the two diverge and the bigger the eventual conflict. Frequent small merges beat one giant one.
• Keep changes focused. Sprawling branches that touch everything collide with everyone. Small, single-purpose branches conflict less.
• Talk to your team. If two people are about to rework the same file, a thirty-second heads-up saves a gnarly merge later.

A merge conflict is a normal, routine part of working with other people in git — not a sign anything went wrong. Read the markers, make the code correct, add and commit. Resolve a few on purpose and it becomes one of the most unremarkable things you do all week.