What is the difference between git add -A and git add .?

In modern Git, both stage additions, modifications, and deletions. Their path scope differs when you run them from a subdirectory.

Best practices
Illustration of Git branches and commit history

In Git 2.0 and later, both commands stage additions, modifications, and deletions within their scope. With no pathspec, git add -A updates the index across the working tree. git add . limits the operation to the current directory and its descendants.

Compare the scope

Command Scope Includes new files? Stages tracked deletions?
git add -A Entire working tree, when no pathspec is supplied Yes, subject to ignore rules Yes
git add . Current directory and descendants Yes, subject to ignore rules Yes
git add -u Entire working tree, when no pathspec is supplied No Yes
git add -A -- src/ The specified path Yes, subject to ignore rules Yes

From the repository root, git add . and git add -A normally cover the same paths. From src/, git add . leaves changes in a sibling directory such as tests/ unstaged, while pathless git add -A includes them.

“All” does not mean every file on disk. Ignore rules still apply to untracked files. Submodule contents belong to separate repositories, and sparse-checkout rules can further constrain what Git will stage.

Choose the command that matches your intent

# Stage changes throughout the working tree.
git add -A

# Stage only the current directory tree.
git add .

# Stage changes under explicitly named paths.
git add -- src/ tests/

# Select individual changes interactively.
git add -p

These are alternatives, not a sequence. Run git status and git diff --cached before committing to check the actual staged snapshot. Explicit paths reduce the scope, but they can still stage unrelated changes within those paths.

Why do older tutorials say something different?

Before Git 2.0, git add <pathspec> without -A did not stage removals in the same way. The default scope of pathless -A and -u also differed when run from a subdirectory. Check git --version when working on an old installation instead of applying historical examples to a modern client.

Frequently asked questions

Is git add * equivalent?

No. An unquoted * is normally expanded by the shell before Git runs. Its behavior depends on the shell and its options; it commonly excludes dotfiles and cannot expand to a deleted path that no longer exists. A quoted wildcard is instead interpreted as a Git pathspec, which is another case. Use an explicit directory or -A when that is the scope you want.

How do I stage only modifications and deletions?

Use git add -u. With no pathspec, it updates already tracked paths across the working tree without adding new files. Supply a pathspec if you want to limit that operation.

How do I undo an accidental staging operation?

In a repository with an existing commit, use:

git restore --staged -- path/to/file

The older equivalent is git reset HEAD -- path/to/file. Both reset that index entry to HEAD while retaining working-tree edits. In a repository with no first commit, HEAD does not yet provide that baseline, so the same unstaging command is not directly applicable.

References

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting