How Merging Works

Set the edge cases aside and a merge ends one of two ways. If the other branch simply continued your line, there is nothing to combine and your branch name slides forward - the Fast-forward of the last chapter. If both lines moved, git ties them with a knot: one merge commit holding both threads. Everything in this chapter is about how that knot gets tied.

$ git show adeac3f:rates.md
office rates
- filing: 0.10
- copies: 0.25 per record

The first thing to unlearn: a real merge never weighs just two things. It weighs three - your tip, their tip, and the base: the commit both lines grew from. For every region of every file, git asks one question - who changed this since the base? One side changed it: take that side. Neither: keep the base's version. Both, identically: take it once. Both, differently: stop and ask you.

office rates
- filing: 0.10
<<<<<<< HEAD
- copies: 0.20 per record
=======
- copies: 0.30 per record
- postage: 0.05
>>>>>>> payments-desk

Content conflicts happen per region, not per file. In the real run below, main and payments-desk both touched rates.md - and look at the file mid-merge: the first two lines merged silently and sit above the markers untouched. Only the one region both sides changed differently is fenced off, both versions preserved, waiting for a ruling. "We both edited the file" does not mean conflict; "we both changed the same lines to different results" does. (Whole-file shapes - edit one side, delete the other - are a later chapter's business.)

The identical-edit case surprises people most: if both sides made the same change to the same line, there is no conflict at all - both agree with each other against the base, and git takes the change once. The rule is never "same lines touched"; it is "same lines, different results".

$ git add rates.md
$ git commit -m "reconcile: payments desk rulings"
[f58c7b4] parents: 57853c4 d65824c ...

Resolving is a ceremony you already know. Edit the fenced region into the ONE version that should exist and delete the marker lines. Then git add the file - add's second meaning: this file is resolved. Then commit: the knot is tied, two parents under one seal. In the real run, that seal is f58c7b4 holding 57853c4 and d65824c. And the exit is always there: git merge --abort abandons the merge and rebuilds the pre-merge desk (start clean and the walk-back is exact) - no shame in stepping out to think.

One honesty note carries the whole chapter: git merges content, never meaning. Two individually correct changes can combine into something wrong that merges perfectly clean - tests and review judge meaning; git only guarantees the combine. A clean merge is a claim about the combine, not about your program.