Merge Conflicts Explained
Few things rattle a new developer like the words "merge conflict." But a conflict is not a failure — it is Git being honest. When two branches changed the same lines in incompatible ways, Git refuses to guess which one you meant and hands the decision to you. Understanding what it is really telling you turns a scary moment into a routine one.
Why conflicts happen
Git merges by comparing each branch against the common ancestor they both started from. If one branch changed a region of a file and the other left it alone, Git takes the change automatically. A conflict arises only when both branches edited the same region in different ways, so there is no single answer that respects both. The classic cause is two people editing the same function, but it can also happen when one branch deletes a block another branch modified.
Because conflicts are about overlapping edits, the best way to avoid them is social as much as technical: keep branches short-lived, pull frequently, and split large files that many people touch. The less time two branches spend diverging, the smaller the overlap when they finally meet.
Reading the markers
When Git cannot merge a region, it writes both versions into the file surrounded by markers. Everything between <<<<<<< and ======= is your current branch's version; everything between ======= and >>>>>>> is the incoming version, and each side is labelled with its branch or commit. The markers are ordinary text that Git inserted — your job is to replace that whole block with the correct final content and delete the markers entirely.
The mistake to avoid is leaving a stray marker behind. A forgotten <<<<<<< or ======= will usually break the file, so after resolving, search the whole project for the marker characters to be sure none survived.
Resolving with a diff tool
The hard part of a conflict is deciding what the merged result should be, and seeing the two versions clearly makes that decision far easier. Copy your side and the incoming side into the two panes of DiffScope — without the marker lines — and compare them directly. The highlighting shows exactly where they diverge, so you can build a final version that keeps the right piece from each, rather than blindly choosing one whole side.
Once you have crafted the resolution, paste it back over the conflicted block, remove the markers, and let the tests confirm the result. Reviewing the before-and-after in a diff one more time is a cheap way to be sure you did not drop a change from either branch.
The takeaway
A merge conflict means both branches changed the same region, so Git asks you to choose. Read the <<<<<<< / ======= / >>>>>>> markers, compare the two sides in a diff to craft the right result, then delete every marker before you commit.
Open the tool and try it now
More guides
How Diff Algorithms Work
Every diff tool answers one question: what is the smallest set of edits that turns one text into another? Here's the idea behind LCS and the Myers algorithm.
Line Diff vs Word Diff: When to Use Each
The same change can be shown as whole swapped lines or as a few highlighted words. Here's why both granularities exist and when each one is clearer.
Reading a Git Diff Without the Guesswork
Those @@ headers and +/- lines look cryptic until you know the pattern. Here's how to read a unified diff line by line and never lose your place.