You just edited five files across three directories. Now what? Before you stage anything or lock in a commit, you need to know exactly what changed. That’s what git status is for.
If you’ve ever wondered what is git status and why developers run it dozens of times a day, this guide breaks it down. The command shows the current state of your working directory and staging area, including modified files, staged changes, and untracked files that Git doesn’t know about yet.
This article covers how to read the terminal output, what each flag does, how git status behaves during merge conflicts and rebase operations, and how the same information shows up in tools like VS Code and JetBrains IDEs. Whether you’re new to version control or just want a clearer mental model of Git’s three-layer system, everything you need is here.
What is Git Status
Git status is a Git command that displays the current state of your working directory and staging area.
It tells you which files have been modified, which changes are staged for the next commit, and which files Git isn’t tracking at all. The command itself doesn’t change anything in your repository. It’s purely informational.
Think of it as a snapshot of where things stand right now. You run it, you see what’s going on, you decide what to do next.
According to Hutte research, roughly 95% of developers run git status daily. That makes it one of the most frequently executed Git commands in any workflow. And it makes sense. Before you stage files with git add, before you lock in changes with git commit, you need to know what state your files are in.
The command sits at the center of the edit-stage-commit cycle that drives all version control work in Git. Without it, you’re committing blind.
Here’s the basic syntax:
“ git status `
That’s it. No required arguments, no flags needed for the default output. Run it in any Git repository and it reports back with everything you need to know about your current branch, staged changes, unstaged modifications, and untracked files.
RhodeCode data shows Git adoption has climbed from 87.1% in 2016 to 93.87% in 2025, based on Stack Overflow Developer Survey results. With that kind of saturation, git status is a command that nearly every working developer encounters on a daily basis.
What Git Status Output Actually Looks Like
The default git status output is verbose on purpose. It groups information into distinct sections and even tells you what commands to run next. Took me a while to appreciate that, actually. Most beginners skim right past those hints.
A typical response starts with your current branch name and its relationship to the remote tracking branch. Then it lists file changes across three categories.
| Output Section | What It Shows | Color in Terminal |
|---|---|---|
| Branch info | Current branch, ahead/behind remote | Default text |
| Staged changes | Files ready to commit | Green |
| Unstaged changes | Modified but not yet staged | Red |
| Untracked files | New files Git doesn’t know about | Red |
When everything is clean, you get the shortest possible output:
` On branch main Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean `
That “nothing to commit, working tree clean” message is what you want to see after finishing a commit. It confirms every change has been recorded.
Staged Changes Section
“Changes to be committed” lists files that have already been added to the staging area through git add.
These are the changes that will be included in your next commit. Git shows them in green text in most terminal configurations, which makes them easy to spot visually.
A single file can show up here as “new file,” “modified,” or “deleted,” depending on the type of change you staged.
Unstaged Changes Section
Files listed under “Changes not staged for commit” have been modified in your working directory but haven’t been added to the staging area yet.
Here’s the part that trips people up. The same file can appear in both the staged and unstaged sections at the same time. That happens when you stage a file, then keep editing it before committing. Git tracks the version you staged separately from the version in your working directory.
If you want line-by-line details on what changed, pair this with git diff for a deeper look at the differences between your working copy and the index.
Untracked Files Section
Any file that exists in your working directory but has never been staged or committed shows up here.
New files always land in this section first. Once you run git add on them, they move to the staged section. If you don’t want Git tracking certain files at all (build artifacts, environment files, node_modules), that’s where .gitignore comes in.
How Git Status Fits Into the Git Workflow
Git status isn’t something you run once. It’s the command you come back to between every other step in the Git workflow.
The typical cycle looks like this: edit files, check status, stage changes, check status again, commit. Then maybe push. Hutte’s research found that 80% of senior developers recommend committing changes frequently with small, incremental commits. Git status is how you verify what you’re about to lock in before each one.
Before Staging
You’ve been writing code for the last hour. Maybe you touched three files, maybe twelve.
Running git status before staging shows you exactly what changed. It prevents the classic mistake of accidentally staging files that weren’t ready, like temporary debug logs or half-finished features. This is especially useful in larger codebases where you might lose track of which files you touched.
After Staging, Before Committing
Confirmation step. You’ve run git add on the files you want. Now you run git status one more time to make sure only the right changes are queued up.
Hutte data shows 60% of developers have accidentally committed unintended file changes or secrets to a repository. A quick git status check before committing catches most of those mistakes. Especially dangerous with API keys or credentials sitting in config files.
Pairing with Other Commands
Git status gives you the overview. Other commands give you the details.
- git diff: Shows exact line-by-line changes in unstaged files
- git log: Shows commit history, not current state
- git stash: Temporarily saves changes when you need a clean working directory
The GitHub Octoverse 2025 report showed developers pushed nearly 1 billion commits that year, a 25% increase over the previous year. Every single one of those commits was (or should have been) preceded by a git status check.
Git Status Flags and Options
The default verbose output is great for learning. But once you’re running git status fifty times a day, you probably want something shorter.
Git ships with several flags that change how the output looks and what gets included.
Short Format Symbols and What They Mean
Running git status -s gives you a compact two-column output. Each file gets a two-letter code on the left side.
| Symbol | Position | Meaning |
|---|---|---|
| M | Left (staging) | Modified and staged |
| M | Right (working tree) | Modified but not staged |
| A | Left | New file added to staging |
| D | Either | Deleted |
| ?? | Both columns | Untracked file |
| R | Left | Renamed |
So M file.js means staged modification. M file.js (note the space) means unstaged modification. And MM file.js means you staged the file, then modified it again before committing.
Add -b to include branch info in the short output: git status -sb. Most developers I know end up aliasing this to something like gs for speed.
Controlling Untracked File Display
The -u flag controls how untracked files show up in the output.
- -u no: Hides all untracked files entirely
- -u normal: Shows untracked files and directories (default behavior)
- -u all: Shows individual files inside untracked directories
Large projects generate a lot of noise from untracked files. If your .gitignore isn’t fully configured yet, -u no cleans up the output while you focus on tracked changes. There's also –ignored, which does the opposite and reveals files that .gitignore is currently hiding.
Git Status and the Staging Area
You can’t really understand git status output without understanding the staging area. This is where most of the confusion lives for people picking up Git for the first time.
The staging area (also called the index) is a holding zone between your working directory and the repository’s commit history. When git status separates “changes to be committed” from “changes not staged for commit,” it’s showing you two different layers of file state.
Why One File Can Appear Twice
Here’s a scenario that confuses almost everyone at first.
You edit app.js. You run git add app.js. Then you edit app.js again. Now run git status. The file shows up in both the staged section (green) and the unstaged section (red).
That’s not a bug. Git staged the version of the file as it existed when you ran git add. Your second round of edits only exists in the working directory. If you commit right now, only the first set of changes goes in.
RhodeCode reports that 72% of developers say version control systems reduce development time by up to 30%. But that efficiency falls apart fast when developers don’t understand the staging area. Running git status before every commit is the simplest way to avoid shipping incomplete changes.
The Three-Layer Mental Model
Working directory: Where your actual files live. What you see in your code editor.
Staging area (index): A snapshot of changes you’ve selected for the next commit.
Repository (.git): The permanent commit history. Changes land here after you run git commit.
Git status compares these layers against each other. Staged changes are the diff between the index and the last commit. Unstaged changes are the diff between the working directory and the index. Untracked files exist only in the working directory and haven’t touched the index at all.
Getting this model into your head is the single most useful thing you can do when learning Git. Everything else, including branching, merging, rebasing, becomes way more predictable once you understand these three layers.
Git Status with Branches and Remote Tracking
Beyond file states, git status also reports on your branch position relative to its remote counterpart. This is the “On branch main” line you see at the top of every status output, followed by tracking information.
Ahead, Behind, and Diverged Messages
“Your branch is ahead of ‘origin/main’ by 3 commits” means you have local commits that haven’t been pushed yet.
“Your branch is behind ‘origin/main’ by 2 commits” means the remote has commits you haven’t pulled down. Running git pull will bring you current.
And the tricky one: “Your branch and ‘origin/main’ have diverged.” This means both you and the remote have commits the other doesn’t. You’ll need to either merge or rebase to reconcile them.
The GitHub Octoverse 2025 report noted that over 180 million developers are now on the platform, with monthly pull request merges averaging 43.2 million. That volume of collaboration makes branch tracking information from git status critical for staying in sync with your team.
The Git Fetch Gotcha
Here’s something that catches people off guard. Git status only knows about remote branches based on the last time you fetched data from the server.
If your teammate pushed three commits an hour ago and you haven’t run git fetch, git status will still say your branch is up to date. It’s comparing against stale information.
Run git fetch first, then git status. Now you'll get the real picture of where your branch stands against origin. Plenty of teams set up their build pipelines and CI systems to flag when branches drift too far apart, but locally, you're responsible for fetching first.
With source control being the backbone of professional software development, understanding what git status tells you about branch position is a non-negotiable part of the job.
Git Status in Merge Conflicts and Rebase Operations
Git status becomes your most reliable guide when things go sideways. Merge conflicts, stalled rebases, failed cherry-picks. These are the moments where the command goes from “nice to have” to “can’t function without it.”
Hutte research shows nearly 90% of developers experience merge conflicts at some point. And according to DEV Community data, resolving those conflicts consumes 10-20% of developer time on collaborative projects.
What Git Status Shows During a Merge Conflict
When a merge fails due to conflicting changes, git status output changes completely. Instead of the usual staged/unstaged sections, you’ll see a new category: “Unmerged paths.”
The output tells you exactly which files have conflicts and what type. Files show as “both modified” when two branches edited the same lines.
` On branch main You have unmerged paths. (fix conflicts and run "git commit")
Unmerged paths: (use “git add <file>…” to mark resolution)
both modified: app.js `
Git won’t let you commit until every file in the “Unmerged paths” list has been resolved and re-staged. That’s the safety net.
Navigating Rebase and Cherry-Pick States
During an interactive rebase, git status shows which operation is in progress and how far along you are. Something like “interactive rebase in progress; onto abc1234.”
It also tells you what to do next. Finish resolving? Run git rebase –continue. Want to bail? Run git rebase –abort.
The same pattern applies to cherry-picks. If a checkout or pick hits a conflict, git status lays out the situation and your options. Atlassian’s Git documentation specifically recommends running git status as the first troubleshooting step when any merge-related operation stalls.
Spotify’s engineering team has publicly discussed adopting trunk-based development patterns partly to reduce the frequency and complexity of merge conflicts across their large distributed teams.
Git Status vs. Other Git Inspection Commands
Git has several commands that show you information about your repository. They overlap a bit, which confuses people. But each one answers a different question.
| Command | What It Answers | Scope |
|---|---|---|
| git status | “What’s changed right now?” | Working directory + staging area |
| git log | “What happened before?” | Commit history |
| git diff | “What exactly changed, line by line?” | File content differences |
| git show | “What’s in this specific commit?” | Single commit details |
Git Status vs. Git Diff
Git status tells you which files changed. Git diff tells you what lines changed inside those files.
They’re complementary. Run status first to see the big picture, then diff to drill into specific files. Most developers use them back-to-back dozens of times per day.
Hutte data shows ‘git reset’ and ‘git revert’ are used by 80% of developers to undo changes. Understanding the difference between status (current state) and these undo commands (state manipulation) is where many beginners trip up.
Git Status vs. Git Log
Key distinction: git status only cares about uncommitted work. Once you’ve committed something, it disappears from the status output entirely.
Git log picks up where status leaves off, showing the chain of commits already recorded. Think of status as the present tense and log as the past tense of your repository.
When to Use Which Command
- Checking what you’re about to commit: git status
- Reviewing a teammate’s recent commits: git log
- Debugging an unexpected file change: git diff
The Stack Overflow Developer Survey 2024, with 65,437 responses across 185 countries, confirmed Git as the standard version control tool. That means these commands aren’t niche knowledge. They’re baseline skills for professional development work.
Common Git Status Messages and What to Do About Them
Some git status messages are straightforward. Others are confusing enough to send you straight to Stack Overflow. Here’s a reference for the ones that cause the most head-scratching.
HEAD Detached at a Specific Commit
The message “HEAD detached at abc1234” means you’re not on any branch. You checked out a specific commit (or a tag, or a remote branch) directly.
Any commits you make in this state won’t belong to a branch. CircleCI’s documentation notes that detached HEAD is one of the most commonly searched Git problems. The fix is simple: run git switch -c new-branch-name to create a branch from your current position.
Your Branch and Remote Have Diverged
“Your branch and ‘origin/main’ have diverged, and have X and Y different commits each.”
Both you and the remote have commits the other doesn’t. You’ll need to either merge or rebase to reconcile. Run git pull –rebase if you want a linear history, or a regular git pull for a merge commit.
With GitHub now hosting over 630 million repositories (CoinLaw 2025 data), diverged branches happen constantly across distributed teams. This message is normal, not alarming.
Nothing Added to Commit but Untracked Files Present
This means your staging area is empty, but Git sees files it isn’t tracking yet.
If those files should be tracked, run git add on them. If they’re build artifacts, logs, or environment configs that should stay out of version control, add them to your .gitignore file.
Changes Not Staged for Commit
You edited files but didn’t run git add. The modifications exist in your working directory only.
This is the most common status message you’ll see during active development. Stage the files you want with git add, or discard changes with git restore if you want to revert them.
Git Status in GUI Tools and IDE Integrations
Not everyone lives in the terminal. Most developers interact with git status through a visual interface in their code editor or a dedicated Git client, whether they realize it or not.
The 2025 Stack Overflow Developer Survey shows Visual Studio Code commanding 75.9% of the developer market. Every one of those installations has Git support baked in.
VS Code Source Control Panel
The Source Control view in VS Code is basically git status with a GUI. It splits changes into the same categories: staged, unstaged, and untracked.
File icons in the explorer also change color and show letters (M for modified, U for untracked, D for deleted) that map directly to what git status would report in the terminal. The status bar at the bottom shows your current branch and sync status with the remote.
VS Code runs git status behind the scenes every time you switch tabs or save a file. The visual layer is just a translation of the same command-line output.
JetBrains IDEs
IntelliJ IDEA, PyCharm, and WebStorm use a “changelists” system that groups file modifications differently than raw git status output.
The default changelist shows all modified files. You can create custom changelists to organize changes before committing, which is their equivalent of selective staging. JetBrains IDEs recorded 27.1% usage in the 2025 Stack Overflow survey, making them the second most popular IDE family behind VS Code.
GitHub Desktop and SourceTree
| Tool | How It Shows Status | Best For |
|---|---|---|
| GitHub Desktop | Changes tab with diff preview | Beginners, simple workflows |
| SourceTree | File status panel + staging area | Visual branching, complex repos |
| GitKraken | Commit panel with drag-and-drop staging | Teams wanting visual Git graphs |
All three of these tools translate git status into a visual format. Staged files, unstaged modifications, untracked files. Same data, different presentation.
Why the Terminal Still Matters
GUI tools are great until they aren’t. Complex merge conflicts, interactive rebases, and edge cases like detached HEAD states are often easier to diagnose from the command line.
Hutte data shows 85% of developers say Git has improved team collaboration. That collaboration happens across different tools and environments. Knowing how to read the raw git status output means you can work in any setup, not just the one your IDE provides.
The source control fundamentals are the same everywhere. GUI or terminal, the underlying data comes from the same place. Your repository doesn’t care how you read its state.
FAQ on What Is Git Status
What does git status do?
Git status displays the current state of your working directory and staging area. It shows which files are modified, which changes are staged for the next commit, and which files remain untracked by Git.
How do I run git status?
Open your terminal inside a Git repository and type git status. No arguments needed. The command outputs your current branch name, tracked file changes, and any untracked files in the directory.
What is the difference between git status and git diff?
Git status tells you which files changed. Git diff shows the exact line-by-line differences inside those files. Use status for the overview, then diff when you need specific details about modifications.
What does “nothing to commit, working tree clean” mean?
It means every change in your working directory has been committed. No modified files, no staged changes, no untracked files. Your repository is fully synced with the latest commit history.
What does git status -s show?
The -s flag gives you a short format output. Each file gets a two-letter code instead of verbose descriptions. M means modified, A means added, ?? means untracked. It's faster to scan.
Why does the same file appear twice in git status?
That happens when you stage a file, then edit it again before committing. Git tracks the staged version separately from the working directory version. Both show up because they differ.
Does git status change anything in my repository?
No. Git status is a read-only command. It inspects the current state of your files and reports back. It never modifies your working directory, staging area, or commit history.
What does “HEAD detached” mean in git status?
It means HEAD points directly to a specific commit instead of a branch. You’re not on any branch. Any new commits won’t be tracked unless you create a new branch from that position.
How does git status work during merge conflicts?
During a conflict, git status shows an “Unmerged paths” section listing every conflicted file. It tells you which files need manual resolution before you can complete the merge and commit.
Can I see git status inside VS Code?
Yes. The Source Control panel in VS Code runs git status automatically. It groups files into staged, unstaged, and untracked categories. File icons in the explorer also reflect modification status in real time.
Conclusion
Git status is the command you’ll run more than any other in your daily workflow. It sits between every edit, every staging operation, and every commit you make.
Understanding its output means you always know where your files stand. Staged, unstaged, untracked, or conflicted. No guessing.
The short format flag (-s`) speeds things up once you’re comfortable reading the default output. And during merge conflicts or rebase operations, git status becomes the first place you look to figure out what went wrong and what needs fixing.
Whether you work from the terminal, VS Code’s Source Control panel, or a JetBrains IDE, the underlying data is identical. The repository state doesn’t change based on how you view it.
Learn to read git status well, and the rest of Git gets easier. Branch tracking, conflict resolution, selective staging. It all clicks faster when you trust what the status output is telling you.
- Android App Bundle vs APK - August 1, 2026
- PHP Cheat Sheet - July 31, 2026
- How Computer Vision, built on existing systems, increases inventory accuracy by 20%+ and protects profit margins - July 31, 2026
