A branch is a 41-byte file
The most important sentence in this whole quest: a branch in Git is a movable pointer to a commit. Not a copy. Not a folder. Not a snapshot. A 41-byte file containing one hash plus a newline. Creating a branch is one filesystem write. That single fact explains why Git encourages branching for everything — feature work, experiments, throwaway debugging, code review — and why teams that came from SVN are amazed by the speed.
Walk into .git/refs/heads/ and you will see this directly. Each filename is a branch name, each file holds the hash of the commit that branch currently points at. main, feature/login, chore/cleanup — they are siblings in a directory. There is no "main is special" magic; convention designates main as the integration branch, and tooling enforces it, but the data shape is identical.
What the pointer points at is the tip of that branch. Walking from the tip backwards via parent pointers gives you the branch's history. Two branches that share old commits both reach the shared commits when walked back. This is how Git computes "what is on feature but not on main" — set difference on reachable commits, no copying involved.
The implications run far. Renaming a branch is renaming the file. Deleting a branch is removing the file (the commits stay, orphaned, until garbage collected). Switching branches updates HEAD to point at a different ref and updates the working tree to match the new tip. Once you see branches as pointers, the rest of branching stops feeling magical and starts feeling like file operations.