Git, Part 2: A Merge Joins Two Lines of Snapshots

Part 1 said a branch is a sticky note on a commit. Part 2 asks what happens when two sticky notes move apart and you want one history again. After this post you should be able to look at a graph and tell a fast-forward from a merge commit, and predict which one git merge will produce before you run it.

This is Part 2 of a six-part series. Part 1 covered commits, branches, and HEAD. Undoing, remotes, rebase, and team workflows come later. We still skip branching-strategy opinions. The question here is mechanical: what objects and refs move?

Interactive Demo

Press Watch demo to walk the diverging path end to end. Watch three beats: feature grows C2 while main stays on C1, main grows C3 so the graph becomes a V, then git merge feature pulses merge node M and amber tokens travel both parent edges. The readout switches to merge: commit.

Reset and try the other path yourself: create feature, commit once, switch to main, merge immediately — the readout should say merge: ff, and main slides onto C2 with no M node. That contrast is the whole lesson.

Code

Two throwaway repos on the same machine. Line endings were left quiet with core.autocrlf false. Hashes will differ on your machine; the shapes will not. Verified with Git 2.43.0.windows.1.

Fast-forward

$ git init -b main
Initialized empty Git repository in .../git-merge-demo/.git/

$ # write readme note, then:
$ git add note.txt
$ git commit -m "Add note"
[main (root-commit) 51520d3] Add note
 1 file changed, 1 insertion(+)

$ git switch -c feature
Switched to a new branch 'feature'

$ # add a feature line, then commit
$ git commit -m "Feature work"
[feature 197e29f] Feature work
 1 file changed, 1 insertion(+)

$ git log --oneline --graph --decorate --all
* 197e29f (HEAD -> feature) Feature work
* 51520d3 (main) Add note

$ git switch main
Switched to branch 'main'

$ git merge feature
Updating 51520d3..197e29f
Fast-forward
 note.txt | 1 +
 1 file changed, 1 insertion(+)

$ git log --oneline --graph --decorate --all
* 197e29f (HEAD -> main, feature) Feature work
* 51520d3 Add note

$ git log -1 --format=parents:%P%ncommit:%h
parents:51520d3577597e12f70b93cc6ec839153e38d470
commit:197e29f

The word Fast-forward is the tell. No new commit id appeared. main and feature both name 197e29f, and that commit still has a single parent. If you re-run git merge feature now, Git reports that you are already up to date — there is nothing left to slide.

Diverged histories

Use different files on each side so the merge can finish without a conflict.

$ git init -b main
$ git commit -m "Add readme"          # 53fd2ac on main

$ git switch -c feature
$ git commit -m "Add feature.txt"     # 925c8cc on feature

$ git switch main
$ git commit -m "Add main.txt"        # 6e2a7d2 on main

$ git log --oneline --graph --decorate --all
* 925c8cc (feature) Add feature.txt
| * 6e2a7d2 (HEAD -> main) Add main.txt
|/
* 53fd2ac Add readme

$ git merge feature -m "Merge branch feature"
Merge made by the 'ort' strategy.
 feature.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

$ git log --oneline --graph --decorate --all
*   6e5a47f (HEAD -> main) Merge branch feature
|\
| * 925c8cc (feature) Add feature.txt
* | 6e2a7d2 Add main.txt
|/
* 53fd2ac Add readme

$ git cat-file -p HEAD
tree 68a7166b8865fecca5a891a9e7b038f668d3418f
parent 6e2a7d2c24b8eb2bd793deaa20e07598ab6e70f6
parent 925c8cc2e29ed449ffaed9ebd6b8b828c7d60f3b
author Dev Example <[email protected]> ...
committer Dev Example <[email protected]> ...

Merge branch feature

Two parent lines means a merge commit. The first parent is the tip of main before the merge (6e2a7d2). The second is the tip of feature (925c8cc). I think reading git cat-file -p HEAD once makes the demo stick better than any diagram alone.

If you want a merge commit even when a fast-forward is possible, pass --no-ff. That is a policy choice about how the graph should look, not a different merge algorithm. Default git merge still fast-forwards when it can. Config merge.ff=false makes --no-ff the default for your machine; leave that alone until your team agrees on a history style.

# Shared starting commit
git init -b main
echo shared > readme.txt
git add readme.txt
git commit -m "Add readme"

# Feature advances alone (fast-forward candidate)
git switch -c feature
echo from feature > feature.txt
git add feature.txt
git commit -m "Add feature.txt"

# Main advances too (histories diverge)
git switch main
echo from main > main.txt
git add main.txt
git commit -m "Add main.txt"

# Merge joins the two tips with a two-parent commit
git merge feature -m "Merge branch feature"