Part III: Chapter 3.3

git status

The Comparison Engine

How does Git magically know exactly which files you modified, which ones are ready to commit, and which ones are brand new? It doesn't run a background watcher service. git status is simply a highly optimized comparison engine between the Three Trees.

Simulating the Diffs

Use the buttons below to walk through a normal editing lifecycle, and click $ git status at any time to see how Git evaluates the state.

HEAD (Repo)

index.js
b2c3d...

Index (Staging)

index.js
b2c3d...

Working Directory

index.js
b2c3d...

Comparison 1: HEAD vs Index

Git looks at the commit that HEAD points to, and compares it to the Staging Area (.git/index).

If a file's hash in the Index is different from its hash in the HEAD commit, it means you have run git add on new changes. Git prints these differences in green under the header "Changes to be committed".

Comparison 2: Index vs Working Dir

Next, Git compares the Staging Area (.git/index) to the actual files sitting in your sandbox (the Working Directory).

If a file on your disk does not match the version sitting in the Index, it means you have modified the file but haven't run git add yet. Git prints these differences in red under the header "Changes not staged for commit".

Connecting Output to Architecture

When you see the standard git status output, you are actually just seeing the results of those two exact comparisons.

Terminal
$git status
On branch main
Changes to be committed: <-- (HEAD vs Index Diff)
(use "git restore --staged <file>..." to unstage)
modified: utils.js
Changes not staged for commit: <-- (Index vs Working Dir Diff)
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: index.js
Untracked files: <-- (Files in Working Dir, but not in Index)
(use "git add <file>..." to include in what will be committed)
README.md