Open a pull request and 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. But when two people change the same line, git stops and asks you to sort it out.

Where a change actually lives

Git keeps your work in a few distinct places. Your working copy is the file as you edit it. git add copies a change into the staging area. git commit snapshots it into your local history. Only git push sends your commits to the remote, where a teammate can git pull them.

  1. 01Working copy
  2. 02Staging area
  3. 03Local history
  4. 04Remote
  5. 05Teammate's pull
The path of one change. A conflict appears when a pull cannot combine two commits.

How git sees a change

Git stores history as snapshots, but when it compares two of them it reasons line by line. Lines present in both versions are anchors; the runs between anchors are edits. Finding the longest common subsequence of lines is what keeps a diff stable even when edits pile up around it.

Why it's a conflict: the merge base

A branch is a movable pointer to a commit. When two people branch from the same commit, their merge base, and edit, their histories fork. Git always reasons relative to that base. If only one side changed a region, git takes the change. A conflict happens only when both sides changed the same lines in different ways.

<<<<<<< ours
owner: ana
=======
owner: marko
>>>>>>> theirs
Git cannot know which owner you meant, so it writes markers and hands the decision to you.

Resolving it: the three-way merge

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 what MergeForge does: a three-pane conflict resolver for VS Code and Cursor, with ours on the left, theirs on the right and the merged result in the middle.

  • Apply all non-conflicting takes every change only one side made, so you spend attention on real conflicts.
  • » / « picks a side for a single conflicting chunk; the result rebuilds instantly.
  • Magic Resolve combines pure insertions from both branches and leaves genuine two-sided rewrites for you.

Under the hood it is a real diff3 three-way merge, the same family of algorithm git uses, tested against git merge-file output down to CRLF versus LF, byte-order marks and trailing whitespace. When a conflict needs judgment, an optional AI assistant can explain it or propose a resolution as reviewable chunks, never a silent rewrite.

MergeForge is available for VS Code and Cursor. See the product page for install links, or read the source and tests on GitHub (opens in a new tab).