Branches
Rachit is halfway through wrecking the homepage on purpose, and the Board needs an urgent fix in the next ten minutes.
Rachit's excited about a redesign — bolder colors, a restructured hero, the works. He starts editing directly on main, same as everyone's been doing so far, because so far that's the only way any of you have worked. Twenty minutes in, half the CSS is rewritten and nothing quite looks right yet. The homepage, right now, on his machine, is genuinely broken mid-thought.
That's the exact moment 06pratyush messages: the event date on the homepage is wrong — it says August 14, should say August 15 — and the Board wants it fixed before it goes out in tonight's newsletter link. A real, small, urgent fix, needed on the working version of the site. Not the half-redesigned one currently sitting in Rachit's working directory.
He's stuck. Finish the redesign first? Could take hours, and it's not ready. Abandon it and lose twenty minutes of work to make the date fix, then start the redesign over later? Also bad. He needs both versions of the homepage to exist at the same time, switchable, without either one touching the other.
What a branch actually is — no metaphor needed
You already know, from Chapter 3, exactly what a commit is: a snapshot, with a hash, pointing back at its parent. And you know HEAD is just Git's word for "which commit your files currently match." A branch adds exactly one more idea on top of that, and it's small enough to say in one sentence: a branch is a name that points at a commit, and moves forward automatically every time you commit while it's the active one. That's the whole mechanism. No overlay sheets, no separate universe — just a second labelled pointer sitting in the same commit graph you already understand.
+ redesign/homepage
+ HEADC
Two names, one commit. Creating redesign/homepage cost nothing — it's a few bytes in a text file, not a copy of the project. The only thing that changed is which name HEAD is currently attached to.
The moment it actually solves Rachit's problem
Here's the part that matters: because redesign/homepage only just got created, it's identical to main right now — same commit C, same files. Rachit can switch back to main this instant, and every wild CSS change he made in the last twenty minutes vanishes from view, safely parked on the other branch, waiting for him.
Nine minutes, start to finish. The date fix went out for the newsletter. The redesign wasn't touched, rushed, or lost. That's the entire value of branches in one concrete afternoon: the trusted line stayed trusted the whole time, while a completely different, half-finished, genuinely risky piece of work sat one command away.
Moving around, and cleaning up after yourself
When you try to switch branches with uncommitted changes that the target branch would overwrite, Git simply refuses rather than silently discarding anything — that protection is exactly why Rachit's first move above was to commit his in-progress redesign as a rough "wip" commit before switching away. (Chapter 10 covers git stash, a lighter-weight way to do the same parking without a commit at all.)
fix/event-date, redesign/homepage, docs/contributing-guide, chore/deps-bump — category first, then what. Six weeks from now, git branch reads like a to-do list instead of a guessing game.
redesign/homepage take less than a second, even though the project has dozens of files?Two weeks later, the redesign is finally ready — genuinely good, Rachit's proud of it, and it's time to bring it into main for real. But in those two weeks, three other small fixes have landed on main that redesign/homepage never saw. Combining two branches that have each moved on their own is a different problem than the clean fast case you just did with the date fix — and this time, there's a real chance both branches touched the same lines.