Summarize this article with:
Every Git commit starts with a single command that most developers run on autopilot. But understanding what is git add and how it actually works changes the way you manage your code.
The git add command moves changes from your working directory into the staging area, preparing them for the next commit. It’s the step between editing files and recording those edits permanently in your repository’s history.
This article breaks down how git add works, its most useful flags, common mistakes to avoid, and how it fits into a real Git workflow. Whether you’re staging your first file or looking to clean up your commit habits, you’ll walk away with a clear picture of what happens every time you run this command.
What is Git Add
git add is the command that moves file changes from your working directory into the staging area. That’s it. Nothing gets saved permanently until you commit.
Think of it as selecting which changes you actually want in your next snapshot of the project. You might have edited five files, but only two of those edits belong in the same commit. git add lets you pick those two.
The Stack Overflow Developer Survey 2024, with 65,437 responses across 185 countries, confirmed that Git remains the most widely used version control system among professional developers. Every one of those developers runs git add before they commit anything.
The command sits at the center of Git’s core workflow: edit, stage, commit. You edit files in the working directory. You stage them with git add. You record them permanently with git commit. Skip the staging step and Git has nothing to commit.
Files in your project exist in one of a few states. They’re either untracked (Git doesn’t know about them yet), modified (changed since the last commit), or staged (marked for the next commit). Running git add is how files move from untracked or modified into staged.
And here’s something that trips people up early on. git add doesn’t just track new files. It also stages updated versions of files Git already knows about. Every time you change a tracked file, you need to run git add again to stage the latest version.
How Git Add Works
When you run git add, Git takes a snapshot of the file’s content at that exact moment and places it in the staging area. The staging area is also called the index, and it lives inside the .git directory of your repository.
This is not a copy of the file in the traditional sense. Git computes a hash of the file contents and stores that blob object in its internal database. The index then references that blob, so Git knows exactly what version of the file you intend to commit.
GitHub’s 2025 Octoverse report showed developers pushed nearly 1 billion commits that year, a 25% increase over the previous period. Every single one of those commits started with staged changes.
Staging Area Explained
The staging area sits between your working directory and the Git repository. It’s a holding zone.
You make changes locally. Then you decide which of those changes belong together in a logical commit. Maybe you fixed a bug and also updated some documentation. Those are two separate concerns, and they probably deserve two separate commits.
Without the staging area, you’d commit everything or nothing. Older version control systems like SVN didn’t offer this kind of granularity. Git’s approach gives you control over your project history.
The index file (.git/index) is a binary file that stores the list of staged file paths, their permissions, and references to the blob objects. When you run <code>git status</code>, it compares your working directory against this index to show you what’s staged and what isn’t.
Git Add Syntax and Common Options
The basic syntax is straightforward, but git add comes with several flags that change its behavior. Knowing which one to use saves time and prevents mistakes.
| Command | What It Does | Best For |
|---|---|---|
| git add | Stages a specific file | Targeted commits |
| git add . | Stages all changes in current directory and subdirectories | Quick staging when all changes are related |
| git add -A | Stages all changes across the entire repo | Full project staging regardless of your directory |
| git add -p | Interactive patch mode, stages by hunk | Splitting changes within a single file |
| git add -u | Stages modified and deleted files only | Ignoring new untracked files |
git add --dry-run lets you preview what would be staged without actually doing it. Useful when you’re not sure what git add . is about to pick up.
According to RhodeCode, Git adoption rose from 87.1% in 2016 to 93.87% in 2025. That’s a lot of developers running these commands daily.
Git Add Patch Mode
The -p flag (short for --patch) is probably the most underused feature of git add. It lets you stage portions of a file instead of the whole thing.
Run git add -p and Git breaks your changes into “hunks.” For each hunk, it asks what you want to do:
- y – stage this hunk
- n – skip it
- s – split it into smaller hunks
- e – manually edit the hunk
- q – quit, don’t stage anything else
Say you fixed a bug on line 12 and also refactored a function on line 85 in the same file. Patch mode lets you commit the bug fix now and save the refactoring for a separate commit. Took me a while to start using this regularly, but once you do, your commit history gets much cleaner.
Git Add vs Git Commit
Beginners mix these up constantly, and it makes sense. Both are part of the same workflow. But they do very different things.
git add selects changes. <code>git commit</code> records them. You can run git add ten times before a single commit. Each git add updates what’s in the staging area. The commit only captures whatever is staged at that moment.
Key difference: Staging is reversible. Commits are (mostly) permanent additions to your project history.
There’s a shortcut, git commit -a, that combines both steps. It stages all modified tracked files and commits them in one shot. But it skips untracked files entirely. And it removes the opportunity to review what you’re about to commit.
Most developers I’ve worked with avoid git commit -a for anything beyond personal throwaway projects. The two-step process exists for a reason. GitHub’s Octoverse 2025 data showed developers merged an average of 43.2 million pull requests per month. Clean, focused commits make those reviews possible.
Git Add vs Git Stage
Quick answer: they’re the same command.
Git introduced git stage as an alias for git add starting around version 2.0. Both commands do exactly the same thing under the hood. Running git stage myfile.txt is identical to running git add myfile.txt.
Some people prefer git stage because the name describes the action more clearly. You’re staging files. The word “add” can be confusing since you’re not really “adding” a file to the repository, just to the index.
In practice, almost everyone uses git add. It’s what you’ll find in documentation, tutorials, and Git command references. Your mileage may vary, but I’d stick with git add to avoid confusing teammates who haven’t seen the alias before.
How to Unstage Files After Git Add
Staged something by accident? Happens all the time. There are two ways to undo it, depending on your Git version.
The Modern Method (Git 2.23+)
Use git restore --staged <file>.
This is the recommended approach if you’re on a recent version of Git. It clearly communicates what’s happening: you’re restoring the file’s staged state back to unstaged.
Your changes aren’t lost. The file goes back to “modified” in your working directory. Nothing gets deleted.
The Classic Method
Use <code>git reset</code> HEAD .
This was the standard way to unstage files before git restore existed. It still works fine and does the same thing. Pulls the file out of the staging area, leaves your working directory untouched.
The difference between unstaging and discarding matters. Unstaging (git restore --staged) keeps your edits. Discarding (git restore without the --staged flag) throws your edits away entirely. Mix those up and you’ll lose work.
Fortune Business Insights reports that approximately 90% of tech startups rely on version control systems as core development tools. For teams that size, knowing how to quickly unstage a file without losing changes is the kind of thing that saves hours over a project’s lifetime.
Git Add with .gitignore
The <code>.gitignore</code> file tells Git which files to skip entirely. When you run git add . or git add -A, Git checks this file first and excludes anything that matches.
Common entries include .env files, build output folders like /dist or /build, IDE configuration directories, and dependency folders like node_modules.
GitHub reported over 39 million leaked secrets in 2024, a 67% increase from the prior year. Most of those leaks happened because developers staged and committed files that should have been in .gitignore from the start.
Force-adding ignored files: You can bypass .gitignore with git add -f <file>. This is occasionally useful, but think twice. If a file is ignored, there’s usually a reason.
One tricky scenario catches people off guard. If a file was already tracked before you added it to .gitignore, Git keeps tracking it. The ignore rule only applies to untracked files. You need to run git rm --cached <file> to stop tracking it, then commit that change.
GitGuardian found 23.7 million new hardcoded secrets in public GitHub commits in 2024 alone. A properly configured .gitignore is your first line of defense, but it’s not enough on its own. Tools like Gitleaks and pre-commit hooks add extra layers of protection against accidentally staging sensitive credentials.
Common Mistakes with Git Add
Most Git problems aren’t about complex merge conflicts or rebasing gone wrong. They’re about git add habits that seem fine until they aren’t.
Staging Everything Blindly
Running git add . without checking <code>git diff</code> first is the most common mistake. You end up with commits that bundle unrelated changes together.
Better approach: Run git status before every git add. Review what changed, then stage only what belongs in the next commit.
The Atlassian Git workflow guide specifically recommends staged, focused commits over bulk staging. It makes code review faster and reverting safer when something breaks.
Forgetting That Git Add Snapshots at Staging Time
This one is subtle. git add captures the file contents at the moment you run it.
Edit a file. Run git add. Edit the same file again. Now commit. Only the first round of edits is in the commit. The second round is still sitting in your working directory, unstaged.
You need to run git add again after every new edit to stage the latest version. It’s not like saving a document where the latest state is always what gets recorded.
Accidentally Staging Sensitive Files
API keys, database passwords, private SSH keys. Developers push these to GitHub more often than anyone wants to admit.
| File Type | Risk | Prevention |
|---|---|---|
| .env | Exposes API keys, DB credentials | Add to .gitignore before first commit |
| .pem / .key | Exposes private keys | Use secret management tools |
| config.json | Exposes service credentials | Use .example template files instead |
| IDE settings | Leaks local paths, tokens | Add .vscode/ or .idea/ to .gitignore |
Deleting a committed secret in the next commit doesn’t fix it. Git history is append-only. Anyone who clones the repo can see the old commit. You’d need to rewrite history with git filter-repo or BFG Repo Cleaner, and even then, the secret should already be rotated.
Confusing git add -A and git add . Behavior
In modern Git (2.x+), these are effectively the same when you’re in the root of the repository.
But in older Git versions (pre-2.0), git add . only staged changes from your current directory down. git add -A staged changes across the entire repo. If you’re working in a subdirectory of a legacy project, this difference can still bite you.
Git Add in GUI Clients and IDEs
Not everyone runs Git from the terminal. The 2024 Stack Overflow survey showed Visual Studio Code used by 74% of developers, and it has Git staging built right into the editor.
The concepts are identical whether you’re clicking buttons or typing commands. You’re still moving files from the working directory to the staging area. The interface is the only thing that changes.
| Tool | How Staging Works | Best For |
|---|---|---|
| VS Code | Click the “+” icon next to changed files in Source Control panel | Developers already in the editor |
| GitKraken | Drag files to the staging area or click “Stage” | Visual learners, complex branching |
| Sourcetree | Checkbox next to each file to stage/unstage | Atlassian/Bitbucket users |
| GitHub Desktop | Checkboxes on changed files (staged by default) | Beginners, GitHub-focused workflows |
| JetBrains IDEs | Changelists group files before commit | Java, Kotlin, Python developers |
GitLens, a VS Code extension, has over 40 million installs and adds deeper Git insights like inline blame annotations and commit history right in the editor. It makes the staging process more transparent without ever leaving your development environment.
JetBrains tools (IntelliJ, WebStorm, PyCharm) take a slightly different approach. Instead of a traditional staging area, they use “changelists” that let you group related changes together before committing. The effect is the same, the presentation is different.
Understanding the command line version still matters, even if you prefer a GUI. When something goes wrong (and it will), the terminal gives you more control. Most GUI tools also let you open a terminal directly if you need to run a specific command that the interface doesn’t expose.
Practical Examples of Git Add in a Workflow
Knowing what git add does matters less than knowing when and how to use it in real work. Here are the situations that come up over and over.
Staging a Single Bug Fix
You fixed a null pointer issue in auth.js. You also cleaned up some comments in utils.js. These are separate concerns.
“ git add auth.js git commit -m "Fix null check in auth handler"
git add utils.js git commit -m “Clean up comments in utility functions” `
Two commits. Each one describes exactly one change. If the auth fix causes a regression, you revert that specific commit without losing the cleanup work.
Splitting Changes with Patch Mode
Best for: when you’ve made multiple logical changes in a single file.
` git add -p api/routes.js `
Git shows each changed section. You press y to stage the parts related to the endpoint fix, n to skip the parts where you refactored error handling. Then commit. Stage the rest separately.
The GitHub Octoverse 2025 report showed developers created over 230 new repositories every minute. Clean commit history from day one makes those repos easier to maintain as they grow.
First Commit on a Feature Branch
You created a new branch and added three new files. They’re all untracked.
` git status git add src/components/Modal.tsx src/styles/modal.css git commit -m "Add modal component and styles" `
Don’t git add . here unless every file in the working directory belongs in the commit. On a fresh feature branch, that might be true. But check first.
Reviewing Before Committing
The strongest habit you can build with Git is reviewing staged changes before every commit.
- git status
shows which files are staged and which aren't
- git diff –staged
shows the actual content of what you're about to commit
- </code>git log –oneline<code> helps you check your recent commit messages for consistency
This three-step check takes about 30 seconds. It catches mistakes before they hit the remote repository and saves you from having to revert commits later.
Microsoft’s continuous integration pipelines on GitHub consumed 11.5 billion GitHub Actions minutes during 2024-2025, a 35% year-over-year increase according to Mordor Intelligence. Every one of those CI runs started with code that was staged, committed, and pushed to a remote. Getting the staging step right means fewer broken builds downstream.
FAQ on What Is Git Add
What does git add actually do?
The git add command moves file changes from your working directory to the staging area. It tells Git which modifications you want included in your next commit. Nothing gets saved permanently until you run git commit afterward.
What is the difference between git add and git commit?
git add selects changes. </code>git commit<code> records them permanently in the repository history. You can run git add multiple times before a single commit. They're two separate steps in the Git workflow.
What does git add . do?
git add . stages all new, modified, and deleted files in the current directory and its subdirectories. It's a quick way to stage everything at once, but review with git status first to avoid staging unwanted files.
What is the staging area in Git?
The staging area (also called the index) is an intermediate zone between your working directory and the Git repository. It holds a snapshot of the changes you’ve selected for your next commit using git add.
How do I unstage a file after git add?
Run git restore –staged on Git 2.23 or newer. For older versions, use git reset HEAD . Both commands remove the file from the staging area without deleting your changes.
What is the difference between git add -A and git add .?
In modern Git (2.x+), they behave the same when run from the repo root. git add -A stages all changes across the entire repository regardless of your current directory. Older versions handled them differently.
How does git add -p work?
The -p flag activates interactive patch mode. Git breaks your changes into hunks and asks whether to stage each one. You can press y, n, or s to split them further. Great for creating focused, logical commits.
Does git add track new files?
Yes. When you create a new file, Git considers it untracked. Running git add starts tracking it and stages it for the next commit. Existing tracked files also need git add after each modification.
Can git add stage deleted files?
Yes. If you deleted a file, git add or git add -A stages that deletion. When you commit, the file removal is recorded in your project history. You can also use </code>git rm<code> for a combined delete-and-stage action.
Does .gitignore affect git add?
Yes. Files matching patterns in .gitignore are excluded when you run git add . or git add -A. You can override this with git add -f , but ignored files are skipped by default to prevent staging build artifacts or sensitive credentials.
Conclusion
Understanding what is git add gives you real control over your project’s commit history. It’s the command that sits between editing code and recording changes permanently in your source control system.
The staging area exists for a reason. It lets you group related changes into focused commits, skip files that don’t belong, and catch mistakes before they reach the remote repository.
Get comfortable with git add -p for partial staging. Always check git status before committing. Set up your .gitignore` early to keep sensitive files out of version history.
Whether you’re staging from the command line or through a GUI client like GitKraken or VS Code connected to GitHub, the core process stays the same. Small, intentional commits built on clean staging habits make your entire software development workflow easier to manage.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, and Speckyboy, and Slider Revolution among others.
- 4 Scalable Hosting Providers for Growing Small Business Websites - April 9, 2026
- 7 Best Private Equity CRM Platforms for Middle-Market Deal Teams [2026 Comparison] - April 8, 2026
- Markdown Cheat Sheet - April 8, 2026
