The words of git stop blurring

You've been copying git commands without knowing what they mean. By the end of this lesson the core words will click, because they all hang off one simple picture: your work lives in four buckets, and every command just moves it between them.

Why this first Your goal is to stop fearing your own repo. Fear comes from not knowing where your work is. Once you can name the bucket your work sits in, git stops feeling like magic you might break.

The whole picture

Forget commands for a second. Git only has four places your work can be:

1 · Working dirYour real files. What you edit in Zed right now.

2 · Staging areaA "packing box": the changes you've chosen for the next save.

3 · Local historySaved snapshots (commits) on your laptop.

4 · RemoteA copy on GitHub. Shared and backed up.

edit a file → git add → git commit → git push →

That arrow line is the four most common commands. Read it as a sentence: you edit a file (bucket 1), git add moves that change into the box (bucket 2), git commit seals the box into history (bucket 3), git push sends it to GitHub (bucket 4). Nothing skips ahead on its own — you move it, one bucket at a time.

The packing-a-parcel analogy Working dir = your desk, covered in stuff. git add = putting the items you want into a box. Staging = the packed-but-open box. git commit = taping it shut and writing a label on it. Local history = the shelf of sealed, labelled boxes. git push = mailing copies to the warehouse (GitHub). You can put things in the box and take them back out before you tape it — that's why staging exists: it lets you choose exactly what goes in each save.

The one command that kills the fear

git status answers: "where does everything stand right now?" It literally tells you which files are in which bucket and what to do next. The whole reason git feels scary is not running it. From now on: git status before you touch anything, and again after.

Try it — in a sandbox you cannot hurt

Open your terminal (Claude Code's CLI is fine, or any terminal) and run these one at a time. This folder is a throwaway — break it all you want. Watch how git status changes as your work moves buckets.

# go to the sandbox and start a repo
cd ~/Claude-Code/learning-git/sandbox
git init                      # turn this folder into a repo (bucket 3 is born)

echo "hello git" > notes.txt  # create a file → it's in the WORKING DIR (bucket 1)
git status                    # see: notes.txt is "untracked" — git isn't watching it yet

git add notes.txt             # move it into STAGING (bucket 2 — the box)
git status                    # see: now "Changes to be committed"

git commit -m "Add notes"     # seal it into LOCAL HISTORY (bucket 3)
git status                    # see: "nothing to commit, working tree clean"

git log                       # see your snapshot in the history

You just walked one change through buckets 1 → 2 → 3, watching git status narrate each step. That loop — change, status, add, status, commit, status — is 90% of everyday git. We'll do bucket 4 (push to GitHub) in Lesson 2.

Check yourself

No peeking at the cheat sheet. Recalling from memory is what makes it stick.

You just edited a file in Zed but ran no git commands. Which bucket is that change in?

Editing only changes bucket 1. Nothing moves until you run git add. That's why git status would list it as "modified" or "untracked".

What does git add actually do?

git add only moves a change from the working dir into the box (staging). Saving the snapshot is git commit; uploading is git push.

A friend says "just push it." Before a push exists, what must you have done?

git push sends commits (bucket 3) to the remote (bucket 4). If you haven't committed, there's nothing to push. Order is always add → commit → push.

Which command answers "where does everything stand right now?"

git status is your dashboard. Run it constantly — it's the antidote to "I don't know what's happening to my repo."

I'm your teacher — ask me anything. Stuck on a word? Confused by what git status printed? Paste it to me in this Claude Code session and I'll explain it against the four buckets. There are no dumb questions here.

Read next (10 min, the best source): Pro Git — "Recording Changes to the Repository". It's the same four-bucket idea in the official book, with pictures.

📄 Cheat sheet: the words & the buckets Next: Lesson 2 — push to GitHub & what origin means