Merge Conflict

What lets a whole team edit the same code at once is the merge, the operation that brings diverged changes back together. When two people edit different parts of one file, the tool stitches both sets of edits in line by line. Twenty people can touch the same file in a week and most of the time nothing goes wrong.

The trouble is the line both people changed. If Theo rewrites a notification string as "3 unread comments" and a colleague rewrites the same line as "3 new comments," which one is right is a decision made outside the code, and the tool has no way to know it. Let the tool pick anyway and the losing edit vanishes without a trace. Nobody notices the missing line, so the discovery happens days later, when someone finds a feature gone and starts working backwards to figure out where it went.

So version control tools chose to stop rather than choose. They leave both edits sitting in the file, side by side, and hold the merge unfinished until a person arrives. The name for that paused spot is a merge conflict. It is worth being clear that this is not damage — it's the tool declining to guess, and it's closer to a safety catch holding on to an edit that would otherwise have been dropped.

The tool decides what to combine by looking at three versions at once: the shared state just before the two sides diverged, your version, and theirs.

1. A line only one side changed takes that change. The other side never touched it, so there is nothing to weigh.
2. A line both sides changed in exactly the same way keeps that single result.
3. A line both sides changed differently stops the merge. That spot is the conflict.

Open the paused file and you'll find markers in place. Your version of the lines sits above, theirs sits below, and a divider runs between them, so both answers are visible on one screen. Resolving goes like this.

1. Pick one of three outcomes: keep yours, keep theirs, or read both and write a new line. The third option is right more often than people expect — if one side polished the wording and the other fixed the arithmetic, both edits need to survive.
2. Delete the markers. Save a file with the divider still in it and that file won't run at all.
3. Tell the tool the file is resolved. The paused merge only continues once you do.
4. Run the tests and open the screen. You assembled that result by hand, so nothing about it has been verified.

There's usually a button that takes one whole side at once, and it's the dangerous part of the interface. Overwrite an entire file with your copy and whatever else the other person put in that file disappears with it, while the merge reports success and nobody notices.

The most common setting is merging a branch — a line of work split off from the main one — that has been sitting for a few days. The longer the two sides stayed apart, the better the odds that the changes piling up on the main line overlap with yours. The first sign is usually a line on the pull request (PR) page saying the branch has conflicts, with the merge button locked.

They also come up during a rebase, which replays your commits onto a new base. That case has a different texture. A merge resolves in one pass, while a rebase lays down one commit at a time, so ten commits that all touch the same file can mean resolving ten variations of the same conflict.

By file type, conflicts cluster in the files everyone edits. Configuration files, dependency lists, route tables — anything where adding a feature means appending one line at the end. Two people each appending a line land in precisely the same position. Files a tool generates rather than a person writes behave the same way, and for those it's safer to regenerate the file than to pick lines out of it by hand.

How often conflicts appear is mostly set by how the team works. Under trunk-based development, where everything lands on the main line several times a day, conflicts are frequent, two or three lines wide, and done in five minutes. On a team that keeps branches alive for three weeks, a conflict shows up once a month and drags ten files with it. The total cost is far higher in the second case.

"This branch has conflicts. Pull the main line, resolve them, and push again."

The merge button is locked, and whoever opened the branch is being asked to sort it out on their side.

"Do you know who changed this line? I'm resolving a conflict and this isn't my call."

Deciding which version survives is a product question, not a technical one, so the person tracks down whoever wrote it.

"Don't just take your own side every time a conflict comes up."

A warning that overwriting someone else's change makes their feature disappear silently.

At Pagedeck, Theo's comment notification branch came back with three conflicts. Two were people appending lines to the end of the same list file, which resolved by keeping both. The third was a notification string: Theo's wording and the wording already on the main line disagreed. Rather than deciding alone, he asked Noa, who had written the original copy. The answer turned out to be neither, and they settled on a third phrasing.

What took time in that scene wasn't deleting markers. It was agreeing on the sentence. Most of the time spent resolving conflicts goes exactly there.

People often read resolving a conflict as a technical chore — soothing an unhappy tool. Unfamiliar markers appear and a few commands are needed to move past them, so it looks that way. But the tool asked for a human because it doesn't know which answer is correct, not because it hit a technical wall. The people who resolve conflicts well aren't the ones who know the most commands; they're the ones who know why the code reads the way it does. Treat it as a technical chore and it gets handed to whoever is free, who has no basis for judging and therefore takes one side wholesale.

The other misreading is that a clean merge means a safe one. No markers appeared, so it feels settled. What the tool examined was whether lines overlapped. If Theo renames a function and a colleague calls that same function from a new file, the two changes never share a line, so they combine quietly and the result doesn't run. Mismatches like that surface in the tests or in code review, never as conflict markers. That's the reason verification steps still stand after a merge finishes without complaint.