Merge

Back when code moved between people as files on a shared drive, whoever saved last won. You'd upload your morning's work, and a colleague who had downloaded the same file that morning and spent the afternoon editing a different part of it would upload theirs — and your morning disappeared. Losing two lines was the good outcome. Losing a full day happened often enough that people stopped being surprised by it.

So teams started locking files. Once someone opened a file, nobody else could touch it until they were done. The overwriting stopped, and waiting took its place. "When are you letting go of the checkout screen file?" came up several times a day, and if the person holding a file went on vacation, that file sat untouchable for a week.

Merging refuses both of those answers. Two people edit the same file at the same time, and when the work comes back together the tool compares the two sets of changes line by line: anything that doesn't overlap gets combined automatically, and only the overlapping lines get handed back to a human. The way teams work now — everyone cutting a branch, a line of work split off from the main one, and rejoining later — rests entirely on that comparison happening by itself.

Pick the receiving side, bring it up to date, combine, then check the result.

1. Move to the receiving side. You run the merge from the line that will receive the changes, not the one that supplies them. Putting a feature branch into the main line means standing on the main line first.
2. Pull the receiving side up to date. If your local copy of the main line is three days old, you are combining against a three-day-old picture of the project.
3. Merge. Non-overlapping changes are stitched together line by line. Where both sides edited the same line differently, the tool stops and reports a merge conflict — the state where automatic combining is impossible. A person opens the file and decides which version survives.
4. Check what came out. Two changes can each work fine alone and break once they sit in the same codebase. Run the tests and open the screen once.
5. A record appears. When the merge finishes, the act of merging is itself recorded as a commit, a point where a set of changes is stored as one unit. This particular record lists both incoming lines as parents, so the history shows where the work split and where it came back together.

In practice step 3 rarely happens on someone's laptop. It happens through a pull request (PR), a request to combine a branch into the main line. The merge becomes one button on a web page, and that button stays locked until a code review approval and the automated checks are in place. That turns merging from a personal call into a team procedure.

Merging earns its keep when several people hold different pieces of work for days at a time and then bring them together. Three situations in particular.

1. Several people building different features in one repository. Everyone cuts their own branch, so a half-finished payments feature never blocks someone else's release.
2. A line of work other people have already downloaded. Replaying your commits onto a new base rewrites their identifiers, so anyone who already pulled that branch ends up with a history that no longer matches yours. A merge leaves every existing record untouched and adds one on top, which sidesteps the problem entirely.
3. Cases where the timing matters later. When someone asks which release a last-minute fix actually went into, the merge record holds the answer.

There are two costs. The first is a history that gets hard to read. Ten people cutting branches and merging thirty times a day produce a graph tangled like a subway map, and working out what landed last Friday turns into its own small investigation.

The second is that delay makes it expensive. The cost of merging scales with how long the two sides were apart. Merge after a day and two or three lines overlap and the whole thing takes ten minutes. Merge after three weeks and ten files disagree, one of them because someone renamed a function you call in forty places. Trunk-based development — merging into the main line several times a day and never letting a branch live more than two days — is a rule built specifically to stay off that curve.

"Can I merge this, or do I need one more approval?"

Not asking for permission. Checking whether the conditions for merging have all been met.

"Pull the main line in and merge it on your side first, then push again."

The branch is sitting on an outdated base, and the reviewer wants the latest main line brought into it before anything goes the other direction.

"We don't merge on Friday evenings."

A team rule: anything that breaks after a merge becomes weekend work, so it waits until Monday.

At Pagedeck, Theo spent five days building comment notifications on his own branch. Seventeen other changes landed on the main line in the meantime, and both sides had touched the notification settings screen. Theo pulled the current main line into his branch, resolved three conflicts there, waited for the tests to pass, and only then opened a pull request. Once the approval arrived, the merge itself was one button.

Doing it in the other order breaks the main line instead. While the conflicts are being sorted out, the main line sits half-broken, and anyone who pulls during that window has their own work stop too.

The most common reading is that a conflict means somebody made a mistake. Red text, several lines of it, and everything halts — it looks like an error. It isn't. A conflict is the tool marking the spots where it declined to decide, and reporting that two people edited the same lines. Read it as an error and people start avoiding conflicts: postponing edits to files others might touch, letting branches sit longer, holding one file and asking everyone else to wait. All three are a slow walk back to locking files, and every postponed conflict comes back bigger.

The second misreading is that a successful merge means the code is correct. The screen says success, which feels like verification. What the tool checked is whether lines overlapped, nothing more. If Theo renames a function and a colleague calls that same function from a new file, the two changes never touch the same line, so they combine quietly and the result doesn't run. Once that reaches the main line, the next person to pull gets a blank screen and spends half a day finding out why. That's why running the tests after a merge is a step in the procedure rather than a suggestion.