Tracking Changes

The three places a change can live

Before the commands, anchor the model. A Git repository has a committed snapshot at HEAD, a staging area called the index, and the files you are editing in the working tree. Tracking changes is the act of comparing and moving content among those places.

The subtle part: git add stages content at that moment, not a magical live link to the file. If you stage a file, edit it again, and then commit, the commit gets the staged version unless you stage again. That is why a file can appear as both staged and modified.

Use status as your map

git status is the command you run before almost every Git decision. It tells you which branch you are on, whether your working tree is clean, which changes are staged, which tracked changes are not staged, and which files are untracked.

git status

When Git says nothing to commit, working tree clean, the index and working tree match HEAD. There is no staged content waiting to commit and no visible unstaged change. When Git lists sections, read them as locations:

For a compact view, use short status:

git status --short
# or
git status -s

Short status uses two columns before the path. The left column describes the index; the right column describes the working tree. So M app.js means a modification is staged, M app.js means a tracked file is modified but not staged, MM app.js means one version is staged and another edit remains unstaged, and ?? notes.txt means the file is untracked.

Read unstaged changes with diff

git diff without extra arguments shows changes in your working tree that are not staged yet. More precisely, it compares the working tree to the index. That makes it your review tool before staging.

git diff
git diff README.md
git diff -- src/parser.js

In a patch, lines beginning with - are removed from the old side and lines beginning with + are added on the new side. The surrounding unchanged lines give context. You do not need to memorize every header immediately, but learn to read the body well enough to answer: is this change intentional, complete, and part of the commit I am about to make?

Inspect the next commit with diff --staged

Once you stage changes, plain git diff may go quiet because there are no unstaged differences left. That does not mean the next commit is empty. It means the difference moved into the index. To inspect staged content, compare the index to HEAD:

git diff --staged
# same idea, older spelling
git diff --cached

This command is the most reliable answer to "what will my next commit contain?" It is also the best final check before writing the commit message. If git diff --staged contains two unrelated ideas, split them before committing. Your future self will thank you when debugging history later.

Stage intentionally with add

git add adds file contents to the index. For a new file, this starts tracking it. For a modified tracked file, this updates the staged version. For a deleted tracked file, broader forms such as git add -A stage the deletion too.

git add README.md
git add src/
git add -A
git add --patch

Use path-specific staging when you know exactly what belongs in the commit. Use git add -A when you have already reviewed the whole working tree and you truly want all additions, modifications, and deletions. The dangerous habit is not -A itself; the dangerous habit is using it as a substitute for reviewing.

Partial staging

Sometimes one file contains two changes: a bug fix and a formatting cleanup, or a feature and a debug print you do not want to keep. git add --patch (or git add -p) lets you stage selected hunks interactively.

git add -p src/search.js

In patch mode, Git asks about each hunk. The most common answers are y to stage the hunk, n to leave it unstaged, s to split a hunk when possible, e to edit the patch manually, and ? for help. This is one of the habits that turns commits from "whatever happened today" into small, reviewable snapshots.

Undo with restore

git restore is for restoring files in the working tree or the index from another source. Used carefully, it answers two different beginner questions: "How do I unstage this?" and "How do I throw away my local edit?"

A daily tracking habit

The practical workflow is simple, but it rewards discipline. Treat the staging area as a draft of the next commit, not as a waiting room for everything you touched.

1. Run git status to see the shape of the worktree.
2. Run git diff to inspect unstaged edits before staging them.
3. Stage only the content that belongs together with git add path or git add -p.
4. Run git diff --staged to review the exact commit draft.
5. Use git restore --staged or git restore -p if the draft includes the wrong content.
6. Commit only when the staged diff tells one coherent story.

That loop is slower than "add everything, commit, hope" for about a week. After that, it becomes faster because your history becomes easier to review, revert, bisect, and explain.

Common pitfalls

Worked examples

git status --short
?? README.md

git add README.md
git diff --staged README.md

git status --short
MM app.js

git diff --staged app.js
git diff app.js

git add -p parser.js
# y = stage this hunk
# n = leave this hunk unstaged
# s = split the hunk if possible

git diff --staged parser.js
git diff parser.js

git restore --staged debug.log

git diff settings.json

git restore settings.json