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.

Who This Is For
  • Developers who already know basic commit and branch actions
  • Readers who want to understand command boundaries and risk
Prerequisites
  • A basic mental model of worktree, index, and commits
  • Comfort reading `git status` and a small commit graph
Common Risks
  • Using local cleanup commands on already shared history
  • Continuing to rewrite before confirming a recovery path

Citations & Further Reading

  1. Git status [Official]
  2. 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 status before changing files or history so you have observable evidence first.
  • Put git status into 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 status surface verifiable information first.

Diagram view

Where inspection commands operateThese commands mainly read repository state and emit information. The key is knowing which layer you are observing.
Observed layers
Working treeIndexCommit historyRefs
Outputs
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 status shows something unexpected, first verify whether you are looking at the working tree, the index, the current branch, or a historical commit.
  • Combining git status with git status, git log, and git show is usually safer than trusting a single output in isolation.

Try it yourself

  1. Practice the git-status command in a test repository and observe state changes before and after
  2. Experiment with different options and compare the output differences
  3. 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: