When a Merge Needs a Commit

A fast-forward works when one branch is only farther ahead on the same path. Sometimes both branches moved after they separated. Then there are two lines of work to retain.

Two lines need a join

Imagine both branches started at commit B. main then made commit C, while simplify-tiers made commit D:

          C  main
         /
A -> B
         \
          D  simplify-tiers

Moving main directly to D would drop C from its line. Moving it nowhere would leave out D. Git instead creates a new commit that joins the two histories:

          C ----\
         /       M  main
A -> B          /
         \     /
          D ---   simplify-tiers

The new commit M is a merge commit. An ordinary commit has one parent, the commit immediately before it. A true merge commit has two parents: the previous tip of the current branch and the tip of the branch that was brought in.

The order carries the direction. If main is current, its previous tip is the first parent. The tip of simplify-tiers is the second. Both remain part of the reachable history, so the merge does not discard either line of work.

A merge commit is still a snapshot

The merge commit records one complete project snapshot, just like every other commit. Its difference is not a special kind of file storage. Its difference is the two parent links that say, “these two lines meet here.”

When the branches changed different files, or different parts of one file, Git can usually build that snapshot without help. It combines the changes and creates the merge commit.

When both branches changed the same lines differently, Git cannot know which final text you intend. It stops before the commit and asks you to decide. That stop is a merge conflict. The two-parent commit has not been created yet, but both parents and all of the work remain available.

The prepared repository is at exactly that stop. Next you will read its state, see how Git marks the alternatives, and learn the safe way back if you are not ready to decide.