Where Your Work Lives

Everything you will ever do in git is movement between three places. The working directory is the folder you edit in; mess is normal there. The staging area holds exactly what your next save will contain - picture an open dossier you are still free to fill, swap, or empty. The repository is the archive of every sealed record, living inside your folder as .git.

The everyday flow runs one way: edit, stage, commit - nothing reaches the repository by accident. Hold that flow as this chapter's map; every part below deepens one piece of it, watched through one real file: Maria's pasta.md, from untracked to sealed.

$ git status
On branch main
Untracked files:
  pasta.md

Create a file and the repository does not react. Maria writes pasta.md and asks for a report: the file sits in the untracked block - git sees it, tracks nothing about it. That silence is a feature: you decide what history records, never the other way around.

$ git status
Changes to be committed:
  new file:   pasta.md
Changes not staged for commit:
  modified:   pasta.md

$ git status --short
AM pasta.md

git add does not mark a file as interesting. It copies the file's bytes, as they are at this second, into the staging area. Maria stages pasta.md, then keeps cooking: one more line lands on the desk copy. (Fine print: under the floor git already files the content in its object store - the Object Store chapter opens it.)

Now the report says two things about ONE file, and both are true: to be committed (the staged copy) and not staged (the desk moved on). In short form that is AM - Added, then Modified. Nothing is wrong; the staging area is simply holding the add-time copy while the desk keeps living. This one screen is the whole staging lesson.

git commit seals what the staging area holds. Only at sealing does the record receive its id - derived from the contents, never assigned in advance. Maria seals: [main 159fa2b] file pasta recipe - 1 file changed, 2 insertions(+). The archive holds it now.

When to seal: one self-contained change per record, with a note that names it. A record whose note says "stuff" helps nobody - including you, next month.

$ git commit -m "file pasta recipe"
[main 159fa2b] file pasta recipe
 1 file changed, 2 insertions(+)

$ git status
Changes not staged for commit:
  modified:   pasta.md

Clean means the three places agree - every FILE line of the report names which two disagree about that file. Right after Maria's seal, the desk still holds the salt line the staging area never saw, so the report is honestly not clean: modified: pasta.md stays until she stages and seals a second record.

$ git cat-file -p HEAD:pasta.md
pasta:
  boil 9 min
  salt the water

$ git cat-file -p HEAD~1:pasta.md
pasta:
  boil 9 min

Git shows you diffs all day, so you assume it stores them. Maria first stages and seals the salt line - git add pasta.md, then [main 65427ef] salt the water - so the newest record now holds it. Open the repository and ask both records for the same file: each answers with the whole file, not a change list. The diff you saw was computed while you watched, from two complete snapshots.

Why whole snapshots win: standing at any moment never replays a chain of patches - git lays the stored snapshot straight out. And because records are filed by their contents, identical content is filed exactly once - Maria's untouched menu.md answers with the same id from both records: acf854c8, twice. Where that number comes from is the next chapter's whole story.

a) Untracked files: pasta.md
b) new file: pasta.md  (staged)
c) AM pasta.md

Exercise - three real reports from this chapter's repo. For each: name which two places disagree, then write the command - or two-command sequence - that carries the desk's truth into the repository. Answers live in the real terminal output above.

Edit ten files, stage two, seal one clean record: the staging area is a composition tool, not bureaucracy. Next door: the number on the record's face - where it comes from, and why it cannot lie.