- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git status Tutorial
Covers how git status shows working tree, staging area, and branch state, and why it should be part of nearly every Git workflow.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
Citations & Further Reading
- Git status [Official]
- Git Basics Recording Changes to the Repository [Book]
What you will learn
- Understand the core purpose of git status Tutorial
- Master the basic usage and common options of git status Tutorial
- Covers how git status shows working tree, staging area, and branch state, and why it should be part of nearly every Git workflow.
- Understand key concepts: What it tells you
- Know when to use this feature and when to avoid it
Start with a problem
You're working in a Git repository and need to perform a specific task — but you're not sure which command or option is the right fit, or what this command can and cannot do.
The short version
git status is the safest and most useful command for checking what is going on in your repository right now.
What it tells you
- current branch
- staged changes
- unstaged changes
- untracked files
- ahead / behind state relative to the upstream branch
Common forms
git status
git status --short
What problem this command solves in a workflow
In the workflow, git status is mostly a “inspect first, decide second” command. It usually does not rewrite history by itself; instead, it helps you confirm the current state of the working tree, index, refs, or commit objects.
Typical use cases
- Use
git statusbefore changing files or history so you have observable evidence first. - Put
git statusinto review, debugging, and incident-analysis flow so the team can align on the same context. - When you need to explain why the repository looks the way it does, let
git statussurface verifiable information first.
Diagram view
Working treeIndexCommit historyRefs
Console outputDiff contextDecision signal
If the output looks wrong, the first thing to question is usually the scope you inspected, not whether the command “worked”.
Special cases and boundaries
- Most inspection commands do not mutate history, but their output still depends on which HEAD, path, range, or ref you asked them to inspect.
- If
git statusshows something unexpected, first verify whether you are looking at the working tree, the index, the current branch, or a historical commit. - Combining
git statuswithgit status,git log, andgit showis usually safer than trusting a single output in isolation.
Try it yourself
- Practice the git-status command in a test repository and observe state changes before and after
- Experiment with different options and compare the output differences
- Simulate a real scenario where you would need to use this, and walk through the full process
Further reading
Keep going on the same topic: