Resolving conflicts without panic

A merge conflict is the thing that makes beginners fear Git — the scary message, the strange <<<<<<< markers in their files, the sense that something is broken. None of that fear is warranted. A conflict is simply Git telling you "two people changed the same lines, and I will not guess which one is right — you decide." Once you understand that, resolving one is a calm, mechanical process. This lesson is resolving conflicts without panic.

When and why conflicts happen

Recall that a commit is a snapshot and merging combines two lines of history (the model and branching lessons). Most of the time Git combines them automatically — if your branch changed file A and someone else's changed file B, there is no conflict; Git just takes both. A conflict happens only when the same lines of the same file were changed differently on both branches. Git cannot know whether to keep your version, their version, or some combination, so instead of guessing (and silently getting it wrong), it stops and asks you.

This is a feature, not a failure. Git guessing could throw away someone's work; instead it hands you the decision. So a conflict is not "Git broke" — it is "Git protected both changes and needs a human to reconcile them." That reframing removes most of the fear.

What a conflict looks like

When a merge (or rebase, or pull) hits a conflict, Git pauses and marks the conflicting spots inside the file with markers:

<<<<<<< HEAD
the version from the branch you are ON (e.g. main)
=======
the version from the branch you are MERGING IN
>>>>>>> feature/thing

Read it as three parts:

Between <<<<<<< HEAD and ======= — your current side (where HEAD is).
Between ======= and >>>>>>> — the incoming side (the branch being merged).
The markers themselves (<<<<<<<, =======, >>>>>>>) are not code; Git inserted them to show you the two options.

git status lists the conflicted files so you know exactly which ones need attention. Nothing is broken; the file just contains both versions, marked, waiting for you to choose.

Resolving it, step by step

The process is always the same, and it is calm once you know it:

See what conflicted: git status shows the files marked "both modified".
Open each conflicted file and find the <<<<<<< markers.
Edit the file to what it should actually be. Keep your side, keep theirs, or — most often — combine them into the correct result. Then delete all three marker lines so the file is clean, real code with no <<<<<<</=======/>>>>>>> left.
Stage the resolved file: git add <file> — this tells Git "I have resolved this one".
Repeat for every conflicted file.
Complete the merge: git commit (for a merge) or git rebase --continue (for a rebase). If things went wrong and you want out, git merge --abort (or git rebase --abort) puts everything back as it was — there is always an escape hatch.

The single most important part is step 3: resolve to the correct code, and remove every marker. A common beginner mistake is committing a file that still contains <<<<<<< markers — that is broken code that will not run. Always search the file for <<<<<<< before staging.

Making conflicts rare and small

You cannot avoid conflicts entirely on a team, but you can make them small and infrequent — which is mostly about habits, not Git commands:

Pull/merge from main often. A branch that is days out of date accumulates far more conflicting change than one you keep current daily. Small, frequent integration means small, easy conflicts.
Keep branches short-lived. The feature-branch workflow (merge within days, not weeks) naturally limits how much can diverge.
Keep changes focused. A giant PR touching hundreds of files conflicts with everything; small, targeted changes rarely collide.
Communicate when two people must touch the same area, so you are not both rewriting the same function in isolation.

Most painful conflicts are really the symptom of a branch that lived too long or a change that was too big. Fix those habits and conflicts shrink to the occasional two-line reconciliation.

Tools that help

You do not have to resolve conflicts by hand in a plain editor if you would rather not:

VS Code (and most editors/IDEs) show conflicts with clickable "Accept Current / Accept Incoming / Accept Both" buttons and highlight the regions — much easier than reading raw markers.
git mergetool launches a configured visual merge tool.
git diff during a conflict shows you the differences to understand what each side did.

Use whatever makes the decision clearest — the goal is the same: produce the correct final code and remove the markers. However you do it, remember the escape hatch: git merge --abort un-does the whole thing if you get into a mess, so you can never truly get stuck. That safety net is exactly why conflicts do not deserve the fear they get.

Check your work

A conflict happens only when the same lines of the same file changed differently on both branches; otherwise Git auto-combines. It is Git refusing to guess and handing you the decision — protection, not breakage.

It looks like three parts in the file: <<<<<<< HEAD (your side) … ======= … >>>>>>> branch (incoming side); the markers are inserted by Git, not code. git status lists conflicted files.

Resolve: git status → open each file → edit to the correct result (yours/theirs/combined) and delete all three marker lines → git add the file → repeat → git commit (or rebase --continue). git merge --abort escapes. Never commit a file still containing <<<<<<<.

Make them rare/small: pull from main often, keep branches short-lived and changes focused, communicate on shared areas. Painful conflicts usually mean a branch lived too long or a change was too big.

Tools: VS Code's Accept Current/Incoming/Both, git mergetool, git diff. Same goal — correct final code, no markers — with --abort as the safety net.

Practice

Deliberately create a conflict: change the same line on two branches and merge them.
Identify the three parts of the conflict markers in the file and say which side each is.
Resolve it by combining both changes correctly, remove all markers, git add and commit.
Create another conflict and use git merge --abort to back out; confirm the repo is as before.
Explain why keeping a branch up to date with main daily makes conflicts smaller.
Resolve a conflict using your editor's visual merge tool instead of raw markers.

Official documentation

Pro Git — Basic merge conflicts — What conflicts are and how to resolve them.
GitHub — Resolving a merge conflict — Step-by-step resolution.
VS Code — Merge conflicts — Resolving conflicts visually in the editor.

Next: pull requests and code review.