`git status` and `git diff`: Your Safety Instruments

Run git status and git diff before committing, switching tasks, or accepting an AI-generated edit. They answer different questions: status summarizes file states; diff shows the content changes behind those states.

Read status as an inventory

The official git status documentation states that it reports differences between HEAD and the index, between the index and working tree, and untracked files not excluded by ignore rules.

In practical terms:

• untracked means the file is present but not in Git’s index;
• modified, not staged means the working copy differs from the index;
• staged means the index contains a change proposed for the next commit; and
• clean means Git sees no tracked or untracked change to report under the current rules.

Clean does not mean correct, tested, backed up, or pushed.

Use two diff views

Run:

git diff

This normally shows unstaged content changes. Then run:

git diff --staged

This shows changes staged for the next commit. The git diff manual documents comparisons among the working tree, index, commits, and paths.

A basic diff includes file headers and hunks. Lines beginning with - were removed from the earlier side; lines beginning with + were added to the later side. Context lines help locate the change. Do not treat every plus sign inside source code as a diff marker; read the leftmost column and headers.

Practice the state transitions

In the tiny practice repository from the previous post:

1. Run git status.
2. Add one sentence to README.md.
3. Create notes.txt.
4. Run git status and git diff.
5. Stage only README.md.
6. Run git status, git diff, and git diff --staged.

Explain where each change lives. The untracked file may not appear in an ordinary content diff because Git has no tracked version to compare, but status still reports it.

Inspect AI edits by scope

Before an AI tool edits:

1. confirm a clean or understood starting state;
2. record the requested files and outcome; and
3. make a checkpoint when appropriate.

Afterward, inspect status for unexpected files and diff for unexpected content. Read every changed line. Run the task-specific tests, then stage only the logical change. An attractive diff is not verification.

Stop if you see credentials, private data, unrelated generated files, unexplained dependency changes, or edits beyond the requested scope.

Common mistakes

• Running only git status and never reading content.
• Reading only unstaged diff after changes were staged.
• Using git add . before understanding untracked files.
• Assuming ignored files are unimportant or backed up.
• Accepting a large AI diff because tests happen to pass.
• Confusing a clean working tree with a synchronized remote.

Do this now

Repeat the six-step exercise. For each command, predict the output first. Restore the practice repository only with commands you understand.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?

Next, turn one reviewed logical change into a useful commit.