If you’re reading this post, chances are you’re looking for a Git command that stages all changes before committing. To set the record straight: the correct command is git add -A. A quick look at the git add documentation will show you that git add -a doesn’t exist. Instead, git add -A is the command that stages all recent changes — including new, modified, and deleted files.

Let’s take a closer look to see if this is the command you’re really after.

Common Mistake: git add -a#

When someone types git add -a, they’re usually trying to stage everything before a commit. It’s often a case of muscle memory or a mistaken assumption that -a stands for “add all.”

In most situations, what the user actually meant was either:

  • git add -A to stage everything, or
  • git add . to stage changes in the current folder and below

git add . vs git add -A#

These two commands are often used interchangeably, but they’re not exactly the same. While both will stage new, modified, and (in modern Git) deleted files, the main difference lies in their scope.

git add -A: Stages Everything, Everywhere#

When you run git add -A, Git stages all changes across the entire working tree, no matter where you are in the project. For example, even if you’re working in a deep directory like src/assets/images, git add -A will still stage changes from higher directories like src/ or the root.

git add .: Stages From the Current Directory Down#

On the other hand, git add . only stages changes in the current directory and its subdirectories. The dot (.) refers to “this folder,” so changes in sibling or parent directories won’t be included.

So, When Does It Matter?#

If you’re working from the root of your repository, there’s practically no difference between git add . and git add -A in modern Git versions — both will stage everything.

But if you’re working in a subdirectory and want to stage all changes in the project, you should use git add -A.

If you only want to stage changes within the folder you’re in, then git add . is the right choice.

Or did you mean git commit -a? 🎯#

Here’s the thing I suspect brought a fair few of you here. -a is a real flag — just on a different command.

git commit -a -m "Fix the login redirect"

Git’s own help describes -a there as “commit all changed files”. It skips the staging step entirely: modified files go straight into the commit without you running git add at all. The usual shorthand squashes the flags together:

git commit -am "Fix the login redirect"

So if you half-remember -a meaning “all” in Git, you’re not imagining it. You’ve just attached it to add instead of commit.

The catch, and it’s a big one: git commit -a only picks up files Git is already tracking. A brand new file you created five minutes ago is untracked, so it is silently left out of the commit. That is the classic “why isn’t my new component on GitHub?” moment, and it’s why plenty of people give up on -am and go back to git add -A followed by git commit -m.

The flag nobody mentions: git add -u#

Sitting quietly between git add . and git add -A is -u, short for --update. It stages every change to tracked files — modifications and deletions — and ignores anything new.

Here’s the difference, run for real. Starting with one modified file (a.txt) and one brand new file (b.txt):

git add -u
git status --short
M  a.txt
?? b.txt

a.txt is staged. b.txt is still sitting there as untracked. That’s exactly what git commit -a does, just as a separate step you can inspect before committing.

It’s genuinely useful when a build has scattered new files around your working directory and you only want to commit edits to things that already existed.

Putting all four side by side#

Command Modified files Deleted files New (untracked) files Scope
git add -A ✅ ✅ ✅ Whole repository
git add . ✅ ✅ ✅ Current folder and below
git add -u ✅ ✅ ❌ Whole repository
git commit -a ✅ ✅ ❌ Whole repository, and commits immediately

Stage half a file with git add -p 🔪#

Once you’re past “stage everything”, this is the flag actually worth learning, and it’s the one that changes how you write commits.

git add -p

Git walks you through your changes one chunk at a time and asks what to do with each. The answers you need on day one:

  • y — stage this chunk
  • n — skip it
  • s — split it into smaller chunks (use this a lot)
  • q — quit, keeping what you’ve staged so far
  • ? — list every option, because there are more

This is how you rescue a messy afternoon where you fixed a bug and renamed some variables and left a console.log behind. Instead of one incoherent commit, you stage the bug fix, commit it, then deal with the rest. Your future self reviewing that history will thank you — and so will anyone reading your pull requests.

Staged something by mistake? Undo it 🔙#

Nothing you’ve staged is committed yet, so nothing here is dangerous. Git even tells you the command — run git status after staging and it prints:

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

So, to unstage one file:

git restore --staged src/index.js

Or everything you just staged:

git restore --staged .

Your edits are untouched — --staged only removes files from the staging area, it doesn’t revert anything you wrote. (git reset HEAD <file> does the same job and is what older tutorials use. git restore is the modern, clearer spelling.)

And if you want to see what a command would stage before committing to it, -n does a dry run:

git add -n .
add 'a.txt'

Frequently Asked Questions (FAQ)#

Is git add -a a valid Git command?#

No — git add -a is not a valid command. Run it and Git replies:

error: unknown switch `a'
usage: git add [<options>] [--] <pathspec>...

The correct command to stage all changes is git add -A. If you wanted to stage and commit in one go, you wanted git commit -a.

Do I need to run git add -A from the root of my repository?#

No, you can run git add -A from any directory inside your project, and it will always stage changes across the entire repository.

Does git add save or commit my changes?#

No. git add only moves changes into the staging area — a holding space between your files and your history. Nothing enters the repository until git commit runs. That in-between step exists so you can choose what goes into a commit rather than being forced to commit everything you happened to touch.

Will git add -A add files listed in .gitignore?#

No. Ignored files stay ignored no matter which of these commands you use. If you genuinely need to stage one, git add -f path/to/file forces it — but stop and ask why it was ignored first.

How do I stage only certain file types?#

Quote the pattern so your shell hands it to Git rather than expanding it itself:

git add '*.js'

That stages every .js file in the repository, from wherever you’re standing.

What if git add -A stages something I don’t want?#

Unstage it with git restore --staged <file>, as above. Better still, get in the habit of running git status before every commit — the two seconds it costs is how you avoid committing a .env file, and there is no comfortable way to un-commit one of those once it’s pushed.

Thanks for being here! 🙌 If you found this post helpful, giving it a like or share means a lot to us — it helps others find it too.

Got another Git command that’s confusing or unclear? Drop a comment below, and we’ll be happy to explain it in a future post or reply directly. We’re here to make Git simpler, one command at a time. 😊

Keep reading#