Branches

The last chapter closed on a glimpse: in git log --graph --all, a second line peeled away from main and later rejoined. This lesson is that peeling away. The surprise is how cheap it is — branching does not copy your project, so making one costs almost nothing, which is exactly why professionals spin up a fresh branch for every task.

What a branch actually is

Before touching a command, get the mental model right — it changes how everything else feels.

A branch is not a copy of your files. It is a movable pointer: a lightweight label that points to one specific commit. That is literally all it is — a 41-byte file on disk containing a SHA hash.

When you create a new commit on a branch, git does two things:

1. Writes the new commit object (snapshot + parent pointer).
2. Moves the branch pointer forward to that new commit.

Because creating a branch just writes one small file, it is instant regardless of how large your repository is. No files are duplicated. No folders are copied. The branch is just a name that says “right now, this label points here.”

HEAD: the pointer to your pointer

HEAD is a special pointer that tells git which branch you are currently on. When you commit, HEAD’s branch moves forward. When you switch branches, HEAD itself moves to point at a different branch.

You can think of it as: HEAD → branch → commit.

Both branches share the first two commits — no duplication. The history only diverges from the point where you created feature.

Creating and switching branches

The modern way (git 2.23+)

git switch -c feature/dark-mode

Switched to a new branch 'feature/dark-mode'

The -c flag means “create.” This is equivalent to two older commands run together: git branch feature/dark-mode followed by git switch feature/dark-mode.

Switch back to main at any time:

git switch main

Switched to branch 'main'
Your branch is up to date with 'origin/main'.

The classic way (still common in docs and CI scripts)

git checkout -b feature/dark-mode

checkout -b does the same thing as switch -c. You will see both in real projects. The newer switch command is preferred because it is more explicit — checkout does too many things.

Listing and deleting branches

List all local branches. The asterisk marks the one HEAD is on:

git branch

* feature/dark-mode
  main

Delete a branch after you have merged it:

git branch -d feature/dark-mode

Deleted branch feature/dark-mode (was d2a9c43).

The feature-branch workflow

This is the pattern behind pull requests on GitHub, GitLab, and Bitbucket:

1. Start from a clean main — make sure main is up to date.
2. Create a branch — git switch -c feature/my-thing.
3. Work and commit freely — make as many commits as you need. Experiment. Break things. None of it touches main.
4. When the feature is ready, merge — switch back to main and merge (covered in the next lesson). Your commits join the main history.
5. Delete the branch — git branch -d feature/my-thing. The commits still exist in main; you are just removing the label.

What switching branches actually does

When you run git switch main, git:

1. Looks at the commit that main points to.
2. Updates every tracked file in your working directory to match that commit’s snapshot.
3. Moves HEAD to point at main.

This is why switching is fast — git is replaying a snapshot it already has, not copying files across disk. On a large repository the checkout of files can take a moment, but the branch mechanics themselves are instantaneous.

In one breath

A branch is not a copy of your project — it is a movable pointer, a 41-byte file holding one commit’s SHA. Committing writes the new snapshot and slides that pointer forward; HEAD is the pointer-to-the-pointer that records which branch you are on. Because making a branch just writes that tiny file, it is instant on any repo, which is why the feature-branch workflow is universal: branch off a clean main with git switch -c feature/x (older form: git checkout -b), commit freely in isolation, then merge back and delete the label with git branch -d (which safely refuses if the work is unmerged — -D forces it). Switching branches simply rewrites your working files to the target commit’s snapshot and moves HEAD.

Practice

Before the quiz, reason about the pointer model: you are on main at commit C2. You run git switch -c feature, make two commits, then git switch main and make one more commit. Where does each of the three pointers — main, feature, and HEAD — point now, and how many commits do the two branches still share?

A question to carry forward

You can now spin off a feature branch, pile commits onto it in total isolation, and leave main pristine the whole time. But a branch that never comes home is useless — the entire point was to eventually fold that work back into main. So picture the moment of return: main has moved on with other people’s commits while your feature was off doing its own thing. How does Git weave two diverging lines of history back into one — and what does it do when both lines changed the very same line of the very same file? That is merging, and it is the next lesson.