How git merge conflicts really work — and how to make them painless

Open a pull request and, behind the scenes, your code has already made a journey: from an edit in your editor, to a commit in your local history, to a push that shares it with everyone else. Most of the time that trip is invisible and smooth. But when two people's journeys cross — when you both change the same line — git stops and asks you to sort it out. To really understand that moment, it helps to watch the whole trip. We'll follow one small change from keystroke to conflict, see exactly what git compared and why it couldn't decide, and then resolve it without ever reading a raw conflict marker.

Where a change actually lives

Git keeps your work in a few distinct places, and every command moves it between them. Your working copy is the file as you are editing it. git add copies a change into the staging area — a holding pen for the next commit. git commit snapshots the staged change into your local history. None of that has left your machine yet — git push is what finally sends your commits to the remote so a teammate can git pull them down.

Drive that pipeline yourself. Follow the owner line of a shared roadmap.yml as your teammate changes it and pushes, then you change it too and pull:

That red box at the end is where most people first meet a conflict — the moment a pull cannot cleanly combine two commits. Before we make it painless, two questions are worth answering: what exactly did git compare, and why couldn't it just choose?

How git sees a change

Git stores your history as a series of snapshots — commits. But when it compares two of them, what it cares about is the diff: which lines changed. It reasons line by line. Lines that appear in both versions are anchors; the runs between those anchors are the edits — lines added, removed, or modified.

Edit the file below and watch git classify every line the moment you type:

The trick that makes this reliable is finding the longest common subsequence — the longest run of lines both versions share — and treating everything between those shared lines as a change. Anchoring on what did not change is what keeps a diff stable even when edits pile up around it. It is the same idea behind git diff.

Why it's a conflict: the merge base

A branch in git is just a movable pointer to a commit. When two people branch from the same commit — their merge base — and start editing, their histories fork. Scrub through the timeline to watch it happen:

Here is the crucial part: git always reasons relative to the merge base. If only one side touched a region, git takes that change automatically — no conflict, no fuss. A conflict happens only when both sides change the same lines in different ways. At that point there is no principled way to pick a winner, so git stops, writes the <<<<<<< / ======= / >>>>>>> markers, and hands the decision to you. That is not git being difficult — it is git being honest about the one thing it cannot know: what you meant.

Resolving it: the three-way merge

You have watched the change travel and seen why the two edits collide. Now settle that same owner clash — without reading a single raw marker. The fix is to look at all three versions at once — the common base, ours, and theirs — and resolve one chunk at a time. That is exactly what MergeForge does: a three-pane visual conflict resolver for VS Code and Cursor.

Ours on the left, theirs on the right, the merged result in the middle. Try it — edit either side and the merge recomputes live:

Three tools cover the whole job:

• Apply all non-conflicting takes every change only one side made, so you spend attention only on the real conflicts.

• » / « pick a side for a single conflicting chunk — the result rebuilds instantly.

• Magic Resolve combines pure insertions from both branches, and deliberately leaves a genuine two-sided rewrite for you. Guessing there would be worse than doing nothing.

None of this is a mock-up. Under the hood it is a real diff3 three-way merge — the same family of algorithm git itself uses — and MergeForge's version is tested against real git merge-file output, down to the details that trip up naive mergers: CRLF versus LF, a byte-order mark, trailing whitespace. When a conflict needs judgment rather than mechanics, an optional AI assistant can explain it or propose a resolution as reviewable chunks — never a silent rewrite of your file.

Try MergeForge

MergeForge is available for VS Code and Cursor. See the product page for install links, or read the source and tests on GitHub. If you build things that touch git, we think you'll like it.