Staging — Choosing What to Save

Lesson 4 · taught by Pip

Here is the plain idea: between editing your files and saving a commit, there's an in-between step where you choose which changes belong in this snapshot. That waiting room is called the staging area.

It feels like one extra step at first. But it's the step that lets a commit capture one clean idea instead of a jumble of everything you happened to change that afternoon.

The desk-and-envelope analogy

Picture our author at a messy desk. Scattered across it: a fixed typo, a new paragraph, a rough note to self, and a half-finished idea that isn't ready.

Before mailing a clean draft to the editor, the author doesn't sweep the whole desk into the envelope. They pick only the finished pieces — the typo fix and the new paragraph — and lay them in the envelope. The rough note and the half-baked idea stay on the desk for later.

The envelope is the staging area. Putting a change into it is called staging. Sealing and sending it is the commit. The desk is your working directory, where messy work-in-progress is perfectly welcome.

The three places your work can be

This gives Git three resting spots for any change, and naming them makes everything click.

The working directory is your live desk — files as you're editing them right now.

The staging area is the open envelope — changes you've chosen for the next commit but haven't sealed yet.

The commit history is the filing drawer — sealed, permanent snapshots.

A change flows left to right: you edit it (working directory), you select it (staging), you save it (commit). You're always in control of when it moves.

Why bother? Clean, focused commits

Say you fixed a typo and started rewriting a whole section in the same sitting. The typo fix is done; the rewrite is a mess. Staging lets you commit just the typo now — a clean, complete save-point — and keep wrestling with the rewrite for a later commit.

Without staging, every commit would be a grab-bag of unrelated changes, and your history would read like a junk drawer. With it, each save-point tells one clear story. That's the entire payoff.

"Add" then "commit"

In Git's own words, putting a change into the envelope is called adding it (the command is git add), and sealing the envelope is committing (git commit). Add, then commit — choose, then save.

Don't worry about memorizing commands. Just hold the rhythm: pick what's ready, then snapshot it. The friendly button apps show this as ticking checkboxes next to changed files, then pressing "commit." Same two beats.

Your turn

Imagine one work session where you did four things to a document: fixed a header, added a paragraph, jotted a private to-do, and started an unfinished table.

On paper, decide which two or three belong in this commit and which stay on the desk. There's no single right answer — the skill is the choosing. That choice is staging.

Next we'll learn to read your history and travel back to any save-point you've made. 🔦