Recall from lesson 1-2 how commits are connected: each commit points back to its parent, forming a chain that runs from newest to oldest.
The links only ever point backwards, so a commit knows where it came from and nothing about what came after it.
Keep that picture, because a branch turns out to be nothing more than a label stuck onto one commit in that chain. The chain does the remembering, and the label only marks a position on it.
A branch is just a movable label
Here is the demystifying fact of the whole course: a branch is a tiny file containing one commit hash. That is all it is, a 41-byte sticky note saying that this line of work is currently at commit c7d8e9f.
You have had a branch all along. main was created automatically by git init back in lesson 2-1. Every time you commit, Git writes the new snapshot and then moves the current branch's label forward onto it, so the label follows the work rather than the work belonging to the label.
HEAD from lesson 3-1 fits above that. Normally HEAD points at a branch, and the branch points at a commit, so being on main literally means HEAD to main to c7d8e9f. That extra level of indirection is what makes committing move the branch instead of stranding it.
Why any of this matters is practical. Because a branch is only a label, creating one copies nothing and takes no measurable time, even in a repository with a million files. Engineers therefore spin up a branch for every experiment, feature, and bug fix, since trying an idea costs nothing and main stays untouched until the idea proves itself.
See the file with your own eyes
This is not a metaphor to take on faith. The file is really there.
Inside .git, every branch is one plain text file at .git/refs/heads/<branch-name>, and its entire contents are a single commit hash followed by a newline. Running cat on it means you have read a branch, in full.
The layout is nothing but ordinary folders and files, which means you can recreate it by hand on your own machine. Doing that is the fastest way to convince yourself how little a branch actually is, and the exercise below does exactly that.
Recreating Git's branch storage by hand
This builds Git's branch directory from scratch and then creates a second branch the way Git itself would, by writing a hash into a file.
mkdir -p repo/.git/refs/heads cd repo echo "c7d8e9f2a91b4c3d5e6f7a8b9c0d1e2f3a4b5c6d" > .git/refs/heads/main echo "Branch files in this repo:" ls .git/refs/heads echo "The main branch label points at:" cat .git/refs/heads/main echo "a9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0" > .git/refs/heads/new-sauce echo "Branch files now:" ls .git/refs/heads echo "new-sauce points at:" cat .git/refs/heads/new-sauce
Output
Branch files in this repo: main The main branch label points at: c7d8e9f2a91b4c3d5e6f7a8b9c0d1e2f3a4b5c6d Branch files now: main new-sauce new-sauce points at: a9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c3b2a1f0
Writing a hash into .git/refs/heads/new-sauce created a branch, and ls now lists one file per branch. That is genuinely almost all git branch new-sauce does, aside from validating the name and reading the current hash for you instead of making you type it.
Two things follow from seeing it this plainly. Deleting a branch is deleting a small file, which is why it never destroys commits, and renaming a branch is renaming that file, which is why it is instant.
Physically, a Git branch is a movable pointer, a stored hash, referring to one commit.
On disk it is about 41 bytes in a file. Nothing about the project's files is copied when a branch is created, which is why the operation is instantaneous even in a repository holding a million files.
That cost profile is the reason branching culture in Git looks the way it does. In older version control systems a branch meant duplicating the tree, so branches were rare and significant, while in Git they are cheap enough to create for a ten-minute experiment and throw away afterwards.
The default branch created by git init is main in modern Git, and older repositories often still call it master.
Technically it is not special in any way. It is a branch like any other, with the same 41-byte file behind it, and Git applies no extra rules to it.
What makes it matter is convention rather than mechanics. Teams agree to treat main as the trusted, working version of the project, which is why the habit is to develop on a separate branch and only bring work into main once it holds up.