Why branches: isolating work without touching main
The problem with one single line of history
Every commit across the last three courses landed on the same branch, main, one after another. That works fine for a solo learning exercise. It breaks down the moment real work looks like this: you're halfway through a risky refactor, a critical bug report comes in, and main needs an emergency fix: right now, without your half-finished refactor anywhere near it.
A branch is Git's answer: an independent line of commits, starting from any point in history, that main never sees until you deliberately bring it back.
A branch is not a copy
This is the single most common misconception worth correcting immediately: creating a branch does not duplicate your project's files anywhere. A branch is a tiny, lightweight pointer: just a name attached to a specific commit's hash, nothing more.
c1 ─▶ c2 ─▶ c3 (main)
↑
HEAD
Three commits, one branch name (main) pointing at the latest one, and HEAD (your current position) pointing at main. Creating a new branch just adds a second name pointing at that same spot:
c1 ─▶ c2 ─▶ c3 (main, feature-x)
↑
HEAD -> main
Nothing was copied. Two labels, one commit. The moment you commit again while on feature-x, the two names finally diverge:
c1 ─▶ c2 ─▶ c3 (main)
\
c4 (feature-x)
↑
HEAD -> feature-x
main still points at c3, completely unaffected: the isolation the emergency-fix scenario needed.
Why this changes how you work
| Without branches | With branches |
|---|---|
| One line of history everyone shares | Independent lines that merge back when ready |
| A half-finished feature blocks urgent fixes | main stays deployable while a feature is in progress |
| Experiments risk breaking working code | A failed experiment is just an abandoned branch, deleted with zero cleanup |
| Only one person can safely work at a time | Multiple people, multiple branches, no collisions until merge time |
The convention on nearly every professional Rails team: main is always deployable. Every feature, every fix, every experiment happens on its own branch and only rejoins main once it's reviewed and ready.
What "checkout" means, and why it's in this course's title
Moving your working tree to match a different branch (or a different commit entirely) is called checking out that branch. The command that does it has a slightly tangled history: worth a short note now, a full lesson later: git checkout historically did two unrelated jobs (switching branches, and discarding file changes: the very command your Git Workflow course's git restore replaced for that second job). This course focuses on the first job: moving between branches.
How this course is organized
- Creating and switching branches
- Inspecting and comparing what's on each one
- Renaming and deleting branches safely
- Detached HEAD: checking out a raw commit instead of a branch
- Branches alongside the remotes from the last course
- Building one real feature entirely on its own branch
Key takeaways
- A branch is a lightweight, movable pointer to a commit, not a copy of your project.
HEADtracks your current position, usually by pointing at a branch name, which in turn points at a commit.- Two branches share history until one of them gets a new commit: that's the moment they diverge.
- The professional convention:
mainstays deployable at all times; all work happens on separate branches first.
Keep going with lesson 2
Creating and switching branches: branch, switch, checkout -b
Creates and switches branches with git branch, git switch, switch -c and checkout -b, and handles uncommitted changes with stash.
A free account also gives you the quizzes, your progress and notes, and the discussion.