Branches — a sandbox for your change

So far, every commit you make stacks onto one line of history. That’s fine when it’s just you on a small project. But the moment a change might break something — or other people rely on the project working — you want somewhere safe to try it first. That’s a branch.

A branch is a cheap, throwaway copy of the whole project where you can experiment without touching the version everyone relies on.

Think of it like “Save As” before you start editing aggressively — except instant and free. The main version (called main) keeps working exactly as it was. Your branch is your own parallel universe. If the experiment pans out, you bring it back into main. If it goes sideways, you delete the branch and it’s as if it never happened.

This is the safety net under Level 5

Remember building and iterating with Claude back in Lesson 5.3? Branches are what make that safe on a real project.

On a branch, you can let Claude attempt something bold — a big refactor, a risky rewrite — and run it hard. If it turns into a mess, you don’t carefully undo each change. You abandon the entire branch. main never saw any of it, so your team’s working version was never at risk. The branch absorbs all the chaos.

That’s the unlock: branches are why “just let Claude try it” stops being reckless and becomes a normal Tuesday.

The Claude way

You name the intent; Claude makes the branch and switches you onto it:

make a branch for the new search feature

Behind the scenes that’s git checkout -b ..., but you don’t need to think in those terms. The one word worth knowing is main — that’s the trunk, the version considered “real.” Everything else is a branch hanging off it, waiting to either join main or be thrown away.

What’s next

Your branch and all its commits still live in exactly one place: your computer. Nobody else can see them — not even a second machine of your own. To change that, you push. Next.