Branching

Imagine you're editing a novel. You want to try a bold rewrite of chapter 3, but you're not sure it'll work — and you don't want to risk the version your editor already approved. The obvious move: photocopy the manuscript, experiment on the copy, and only merge the rewrite back in if it's actually better. A Git branch is that photocopy — except it costs almost nothing to make, because it isn't really a copy at all.

A branch is a pointer, not a folder

This is the single most important mental model for branching. Git doesn't duplicate your files when you create a branch. It creates a tiny pointer — just a name, like feature/login-form — that refers to a specific commit. Your default branch (usually called main) is a pointer too; it's not special to Git beyond being where you started.

When you make a new commit while "on" a branch, Git simply moves that branch's pointer forward to the new commit. That's why branching is instant even in enormous repositories — it's creating a label, not copying gigabytes of files.

Creating and switching branches

# create a new branch (doesn't switch to it yet)
git branch feature/login-form

# switch to it
git switch feature/login-form

# or do both in one step
git switch -c feature/login-form

You'll also see the older, more general command for switching, which still works everywhere:

git checkout feature/login-form
git checkout -b feature/login-form   # create + switch, older-style

git switch was introduced later specifically to handle branch switching, since checkout historically did several unrelated jobs (switching branches, restoring files, and more) and could be confusing. Both work; switch is the clearer choice for new code.

Seeing where you are

git branch

  main
* feature/login-form
  bugfix/nav-overlap

The asterisk marks your current branch. HEAD is Git's internal name for "the commit I'm currently looking at" — normally that's the tip of whatever branch you're on.

Why this enables parallel, safe work

Because branches are cheap and isolated, teams routinely have many active at once — one per feature, one per bug fix, one for an experiment nobody's sure about yet. Nobody's unfinished work can break anyone else's, because each branch's commits only affect that branch until it's deliberately combined with another (that combining step is exactly what Lesson 4 covers).

git switch -c experiment/color-scheme
echo "body { background: navy; }" >> styles.css
git add styles.css
git commit -m "Try a navy color scheme"

git switch main
cat styles.css

Next up: once your branch's work is ready, how do you actually bring it back together with main? That's merging — and its close cousin, rebasing.