Merging Branches

git merge integrates the changes from one branch into another by creating a new snapshot that combines both histories. What actually happens under the hood depends entirely on the relationship between the two branches' commit graphs: if one branch is simply ahead of the other with no divergent commits, Git performs a fast-forward merge; if both branches have unique commits since they diverged, Git performs a true three-way merge, producing a new merge commit with two parents. Understanding which case applies explains a lot of behavior that otherwise seems inconsistent, such as why merging sometimes produces an extra 'Merge branch' commit and sometimes doesn't.

A fast-forward merge happens when the branch you are merging into (say, main) has had no new commits since the feature branch diverged from it — meaning main's tip is a direct ancestor of the feature branch's tip. In this case there is nothing to actually combine; Git simply moves the main pointer forward to match the feature branch's latest commit. No new commit is created, and the resulting history looks perfectly linear, as though the work had been done directly on main all along.

When both branches have diverged — each has commits the other lacks — Git cannot simply move a pointer. Instead it identifies the common ancestor (the merge base) and performs a three-way comparison between that ancestor, the tip of the current branch, and the tip of the branch being merged in. Git then creates a new merge commit with two parent pointers, recording that this snapshot unifies both lines of history. This merge commit is what shows up as the diamond shape in git log --graph output, and it is what future commands like git log --first-parent can use to distinguish mainline history from feature work that was merged in.