Terminal.Drill Get the app
ch08/l01

Working tree, index, commit

Know exactly where a change is before committing or switching context.

git status 20 min read, 25 min lab operator

Git has multiple places work can live: working tree, index, commits, branches, and remotes. `git status` is the first read because it tells you what is modified, staged, untracked, and related to upstream.

In the field

You need to make a focused fix while unrelated local work exists.

Worked command

$ git status --short$ git diff -- app.js$ git add -p app.js$ git commit -m 'Fix terminal prompt copy'
Anti-pattern

Do not stage everything because it is fast.

Safer pattern

Inspect status, inspect diff, stage intentionally, then commit.

Knowledge check

You have two unrelated edits in app.js and want to commit only the prompt-copy fix. What does staging with `git add -p` actually buy you?

  • A It lets you choose individual hunks so unrelated changes stay out of the commit
  • B It commits the staged hunks immediately, skipping the commit step
  • C It discards the hunks you do not select from the working tree
  • D It guarantees the file has no syntax errors before staging
Show the answer

Correct: A. It lets you choose individual hunks so unrelated changes stay out of the commit

Why

`git add -p` walks you through hunks so you stage only the focused change, keeping the commit clean. It never commits and never discards the skipped hunks; they simply stay unstaged in the working tree for later.

Practice checklist

  1. Create a throwaway repo.
  2. Make two unrelated edits.
  3. Stage only one hunk with `git add -p`.

Deliverable evidence

  • Status before and after staging.
  • A commit with one focused change.
Teaching diagramch08 · mental model
Where your work lives working tree edited files index staged commit / branch local history remote origin add -p commit push pull --ff-only git reflog local log of every HEAD move, even after reset save point before repair: backup branch / stash reset --hard discards work never a reflex

shows: The states work passes through (working tree, index, commit/branch, remote), the commands that move it between them, and reflog as the local-only save-point net that reset --hard can otherwise destroy.

does not prove: It does not prove your repository is recoverable: reflog only protects commits Git has actually recorded, so unstaged or untracked working-tree changes wiped by reset --hard are not in scope and stay gone.

Memorize this

Commit these to memory, then drill them until recall is automatic.

git statusgit diffgit add -pgit commit

Reference

git add -pgit log --oneline --graph
Recall practice · Scenario -> next check

cue You want to stage only part of a modified file, hunk by hunk, instead of the whole file.

show recall target

git add -p

See this drill type Practice recall in the app