Branches: parallel universes

Your main line of work runs fine — the project builds, everything works. Now you want to try a big idea: rewrite the layout, change the data model, refactor something that touches everything. If you do it directly on main and the idea fails halfway, you are stranded: main is broken, the working bits are tangled with the abandoned bits, and unwinding them is manual surgery.

The copy-the-folder trick people use for this — project-experiment beside project — works but forgets one thing: you keep working on the original while experimenting, and the two folders drift apart in silence. Merging them later is a nightmare of which-file-is-newer.

Here is the truth that makes branches stop being scary: a branch is not a copy of your project. It is a tiny movable label stuck on one commit — that is all. main is a label pointing at your newest photograph. Creating a branch is writing a second label. It takes no space and no time; that is why professionals create them constantly.

When you commit while standing on a branch, that branch's label slides forward to the new photograph — and the other labels stay exactly where they were. The two lines of history have diverged, each with its own commits, sharing everything that came before the split.

And the trick that makes it feel like magic: the files you see on disk always match the branch you are standing on. Switch branches, and your folder becomes that universe — files appear and vanish to match. One folder, many universes, one switch command away.

In real projects, almost nobody commits directly to main. The rhythm is: make a branch for each piece of work, commit freely on it, and when the idea proves out, merge it back into main. main stays working the whole time — it only ever receives finished, tested ideas.

The next three courses walk exactly that road: create a branch, move between branches, and finally merge one home. The commands are almost boringly small — the mental model above is what makes them feel safe.