The Three Places a File Can Be
This is the page that makes Git predictable, and it is worth reading slowly. Everything after it is easier if this sticks, and everything after it is confusing if it does not.
A file in a repository is in one of three places. Every command in this book moves a change from one of them to another. That is the whole system, and the reason Git's error messages suddenly become readable is that almost all of them are telling you which place your change is currently sitting in.
Packing a parcel is a fair picture. There is the desk, covered in everything you own. There is the open box, holding what is going into this particular parcel. And there is the parcel, sealed and posted, which you cannot casually change any more.
The working directory
The working directory is the files as they exist right now — the ones your editor opens, the ones you see in the folder. Change them, delete them, rewrite them: Git does not react and does not care until you tell it to.
This is the desk. It is where all the actual work happens, and it is also the only one of the three places where a change has never been recorded anywhere.
The staging area
The staging area is a waiting room. You put into it exactly the changes that belong in your next commit, and nothing else.
It exists because real work is messy. You are halfway through restyling the header when you notice the meeting time is wrong, so you fix that too. Now the folder contains two unrelated changes. Without a waiting room, your only options are to record both together — producing a commit nobody can describe — or to undo one of them and redo it later.
Staging lets you say: this fix goes in now, the styling stays where it is. That is the box, and the fact that you choose what goes into it is the entire point.
The history
The history is the sequence of commits. Once a change is here it is recorded, and recorded means findable: almost everything in Chapter 4 is possible because committed work is genuinely hard to lose.
This is the posted parcel. In normal use you do not go back and alter one; you send another.
The two moves
git add moves a change from the working directory into staging. git commit takes everything currently staged and records it in the history.
Two commands, two moves. You will run that pair several times an hour for the rest of your working life, and topic 08 runs it twice so it stops feeling like a ritual.
Both moves have a reverse, and both reverses are in Chapter 4. That symmetry is not decoration — it is why the undo chapter is organized by exactly these three places rather than by command name.
Why not one step
The obvious question: why make people say "add" and then "commit" when the computer could just record everything that changed?
Because "everything that changed" is almost never one idea. Git makes you state what belongs together, and in exchange you get a history where each entry is a single comprehensible thing. The cost is one extra command. The benefit shows up the first time you need to undo one change from last Tuesday without undoing the four unrelated ones that travelled with it.
Plenty of other tools make the opposite choice, and this is a genuine design trade-off rather than an obvious win. Git chose deliberate.
- "Saving in my editor tells Git something." Git has no idea your editor exists. Saving changes the working directory and nothing else — no staging, no recording, no notification.
- "Staged means saved." A staged change that is never committed is exactly as fragile as an unsaved one. Only commits are recorded.
- "Staging is an extra step that wastes time." It is what makes a clean history possible. One command buys you the ability to record one idea while another sits half-finished in the same folder.
- "The three places are three folders on my disk." Only the working directory is a folder you can see. Staging and history both live inside
.git, which is why they survive when you edit or delete a file.
- Every confusing message in the next nine chapters — "changes not staged for commit", "nothing added to commit but untracked files present" — is Git naming one of these three places. Once you can hear that, its messages stop being noise.
- The whole of Chapter 4 is organized by this model: what you type to undo something depends entirely on which place the change has reached.
- Understanding why staging exists is what stops people from treating
git add .as a magic prefix and committing things they never looked at.
Knowledge Check
You edit style.css and save it in your editor. Where is that change?
- In the working directory, and Git has not yet been told anything about it at all
- In the staging area, because saving a file automatically prepares it for the next commit
- In the history, because Git watches the folder and records changes as they happen
- Nowhere yet, because Git ignores a file until it has been committed at least once
Why does the staging area exist at all?
- So you can record one coherent change while unrelated work sits unfinished beside it
- So Git has time to check your files for errors before they are recorded
- So changes can be recovered if the commit command fails part way through
- So several people can prepare changes to the same file before it is committed
Which of the three places has never recorded anything, making changes there genuinely fragile?
- The working directory, where a change exists only as the current contents of a file
- The staging area, because it is emptied every time a commit is made
- The history, because commits can be replaced by newer versions of themselves
- All three equally, since Git only writes anything to disk when you push it
Which pair of commands moves a change all the way from your editor into the history?
git addto put it in the box, thengit committo record all of itgit saveto keep it locally, thengit pushto make it permanentgit initto prepare the folder, thengit statusto confirm it workedgit commiton its own, because it records every change in the folder
You got correct