Introduction

git add -A and git add . are similar, but they are not identical. The main difference is scope. git add -A stages changes across the entire repository, while git add . stages changes under the current directory and its descendants.

In modern Git, both commands can stage new files, modifications, and deletions within their scope. The confusion usually comes from older Git behavior and from running the command in a subdirectory rather than the repository root.

Use git add -A for Repository-Wide Staging

git add -A means "stage all changes everywhere in the repo."

git add -A
git status

This stages:

• new files
• modified files
• deleted files

and it does so across the whole repository, not just from where you happen to be standing in the directory tree.

That is why git add -A is often the safer choice when you truly mean "prepare all current changes for commit."

Use git add . for the Current Directory Tree

git add . stages changes only from the current directory downward.

cd src
git add .
git status

If you are inside src, Git stages changes inside src and its subdirectories. Changes elsewhere in the repository are left alone.

That is the real practical difference. In modern Git, the question is less about whether deletions are included and more about which part of the repository tree you want to stage.

See the Scope Difference in Practice

Suppose your repository looks like this:

• 'src/app.js modified'
• 'docs/readme.md modified'
• 'logs/debug.log deleted'

If you run from the repository root:

git add .

then everything under the root is within scope, so all those changes can be staged.

But if you run from src:

cd src
git add .

then only changes inside src are staged. The modifications in docs and the deletion in logs remain unstaged.

That is why people sometimes think git add . "missed" something. It usually did exactly what its path scope implied.

Why Older Explanations Cause Confusion

You will still find older explanations claiming that git add . does not stage deletions while git add -A does. That description reflects older Git behavior and older habits more than the modern practical distinction most developers deal with today.

If you are using a current Git version, the safer mental model is:

• 'git add -A: whole repository'
• 'git add .: current directory subtree'

That model matches day-to-day usage much better.

Common Pitfalls

The biggest mistake is running git add . from a subdirectory and assuming it means "stage everything in the repo."

Another common issue is memorizing old Git explanations without checking the version and the actual command scope.

It is also easy to use git add -A reflexively when you only meant to stage one focused part of the tree. That can pull unrelated changes into the next commit.

Finally, always verify the result with git status instead of assuming the staging scope matched your intent.

One adjacent command worth remembering is git add -u, which stages tracked-file modifications and deletions but not brand-new untracked files.

Summary

• 'git add -A stages changes across the entire repository.'
• 'git add . stages changes under the current directory and its subdirectories.'
• In modern Git, both can stage new, modified, and deleted files within their scope.
• The key difference is path scope, not just file type behavior.
• Use git status after either command to confirm what was actually staged.