Skip to Content
Navigation:

A stick figure smiling

If you want to see more comics like this, sign up for my saturday comics newsletter or browse more comics!

Image of a comic. To read the full HTML alt text, click "read the transcript".

browse more comics! get the zine!
read the transcript!

You can think about a Git branch in 3 different ways.

Each of the three ways is illustrated with a diagram of a vertical line divided up into four nodes, labelled “main”. A diagonal line with three nodes is coming off the second node from the bottom, labelled “branch”.

way 1: just the commits that “branch” off

In this diagram, the two nodes that are on the branch, but not on the main, are labelled “these two”.

This is what you’re probably thinking about when you merge or rebase a branch into another one.

Git doesn’t keep track of which branch another branch is “based” on though: that’s why you have to run git merge main (you have to tell it which base branch to merge with!)

You can see these commits with:

git log main..BRANCHNAME

way 2: every previous commit

In this diagram, the same two nodes are indicated as in way 1, plus the node on main that the branch comes out of, and the node on main before the branch.

This is what git log BRANCHNAME shows you.

When we say a commit is “on” a branch, we mean that it’s somewhere in the history for that branch.

way 3: just the commit at the end

In this diagram, the one node on the branch farthest from where main and branch diverge is labelled “this one”.

This is how git represents a branch internally. You can run:

cat .git/refs/heads/BRANCHNAME

to see the commit ID for the branch.

That commit’s parent (and grandparents, great-grandparents, etc) determine the branch’s history.

Saturday Morning Comics!

Want another comic like this in your email every Saturday? Sign up here!

I'll send you one of my favourite comics from my archives every Saturday.
© Julia Evans 2024 | All rights reserved (see the FAQ for notes about licensing)