git status is a read-only command in Git — the version control system used to track changes to files over time — that answers a single question: “Compared to the last thing I saved, what has changed in my project right now?” It does not save anything, undo anything, or send anything anywhere. It simply reports.

To understand why this matters, picture a real, everyday scenario. You’re building a small website. Yesterday you saved (committed) a version with a working homepage. Today, before lunch, you edited the navigation bar, created a new file called about.html, and accidentally left a stray console.log in your JavaScript file. You’ve been distracted and can’t quite remember everything you touched. Running git status instantly lists: the navigation file as modified, about.html as untracked (brand new, Git doesn’t know about it yet), and reminds you nothing has been staged for the next snapshot. In three seconds, you have a complete, accurate picture of your workspace — something that would take real effort to reconstruct from memory alone.

It helps to understand the three “zones” a file in a Git project can live in, because git status is essentially a report on which zone every file currently sits in:

git status compares all three zones simultaneously and tells you, file by file, where the differences are. That’s the whole concept. Everything else in this article is detail on how it does that comparison and how to read what it tells you.

Under the hood, git status doesn’t “ask around” or check a log file — it performs a live, direct comparison of three data structures every time you run it. Understanding these three structures is the key to understanding almost everything else in Git, not just this one command.

Every file change in Git is ultimately tracked through a content fingerprint called a SHA-1 hash — a unique 40-character code generated from a file’s exact contents. If you change even a single character in a file, its hash changes completely. git status uses these hashes (by way of the index) to decide, with mathematical certainty rather than guesswork, whether a file is truly different from the last commit.

It’s easier to understand git status by following one single file through its entire lifecycle — from the moment it’s created to the moment it’s safely committed.

flowchart LR
    A["New file created\non disk"] -->|"git status shows:\nUntracked"| B["Working Directory"]
    B -->|"git add"| C["Staging Area\n(Index)"]
    C -->|"git status shows:\nChanges to be committed"| D{"Ready to\ncommit?"}
    D -->|"git commit"| E["Repository (HEAD)\nPermanent snapshot"]
    B -->|"edit tracked file"| F["git status shows:\nChanges not staged"]
    F -->|"git add"| C
    E -->|"edit again"| F
    

Walking through this diagram in plain language: a brand-new file starts completely unknown to Git — this is the Untracked state. The moment you run git add on it, it moves into the staging area, and git status now reports it under “Changes to be committed.” If you go back and edit a file that Git already knows about (one that’s been committed before), it appears under “Changes not staged for commit” because the working directory now differs from what’s in the index. Only when you run git commit does the staged content become a permanent part of the repository’s history, and the cycle can begin again on the next edit.

When you run git status in its default (long) form, it prints output organized into clearly labeled sections. Here is what each one means and, critically, why Git separates them the way it does.

A file can only ever be listed in one category per comparison, but a single filename can appear in both the staged section and the unstaged section at the same time — this happens when you stage a change, then keep editing the same file afterward. Git is telling you, correctly, that part of your work is queued for the next commit and part is not.

The default output of git status is friendly and verbose, which is great for learning but can feel slow to read once you’re working with it dozens of times a day. Git provides several flags to change how the information is presented, without ever changing what is actually being checked.

The core trade-off is between completeness and speed of reading. The long-form output is deliberately educational and includes helper hints, which is perfect while learning, but professional engineers almost always switch to -sb or a shell-integrated short status once they’re comfortable, trading friendliness for speed of scanning.

• Run it before you touch anything. Make it a reflex, the very first thing you do when returning to a project — it tells you whether you left work uncommitted last time.
• Run it before staging. Confirm what’s actually changed before running git add, so you don’t accidentally stage files you didn’t mean to include.
• Run it right before committing. A final check of the “Changes to be committed” section prevents half-finished or unrelated changes from sneaking into a commit.
• Use .gitignore alongside it. If build artifacts or dependency folders keep cluttering your “untracked files” list, add them to .gitignore so the output stays meaningful.
• Pair it with git diff. Use git status to see which files changed, then git diff to see exactly what changed inside them.