Difference between "git add -A" and "git add ."

This answer only applies to Git version 1.x. For Git version 2.x, see other answers.

Summary:

• git add -A stages all changes

• git add . stages new files and modifications, without deletions (on the current directory and its subdirectories).

• git add -u stages modifications and deletions, without new files

Detail:

git add -A is equivalent to git add .; git add -u.

The important point about git add . is that it looks at the working tree and adds all those paths to the staged changes if they are either changed or are new and not ignored, it does not stage any 'rm' actions.

git add -u looks at all the already tracked files and stages the changes to those files if they are different or if they have been removed. It does not add any new files, it only stages changes to already tracked files.

git add -A is a handy shortcut for doing both of those.

You can test the differences out with something like this (note that for Git version 2.x your output for git add . git status will be different):

git init
echo Change me > change-me
echo Delete me > delete-me
git add change-me delete-me
git commit -m initial

echo OK >> change-me
rm delete-me
echo Add me > add-me

git status
# Changed but not updated:
#   modified:   change-me
#   deleted:    delete-me
# Untracked files:
#   add-me

git add .
git status

# Changes to be committed:
#   new file:   add-me
#   modified:   change-me
# Changed but not updated:
#   deleted:    delete-me

git reset

git add -u
git status

# Changes to be committed:
#   modified:   change-me
#   deleted:    delete-me
# Untracked files:
#   add-me

git reset

git add -A
git status

# Changes to be committed:
#   new file:   add-me
#   modified:   change-me
#   deleted:    delete-me

Both git add . and git add -A will stage all new, modified and deleted files in the newer versions of Git.

The difference is that git add -A stages files in "higher, current and subdirectories" that belong to your working Git repository. But doing a git add . only stages files in the current directory and subdirectories following it (not the files lying outside, i.e., higher directories).

Here's an example:

/my-repo
  .git/
  subfolder/
    nested-file.txt
  rootfile.txt

If your current working directory is /my-repo, and you do rm rootfile.txt, then cd subfolder, followed by git add ., then it will not stage the deleted file. But doing git add -A will certainly stage this change no matter where you perform the command from.

The -A option adds, modifies, and removes index entries to match the working tree.

In Git 2 the -A option is now the default.

When a . is added that limits the scope of the update to the directory you are currently in, as per the Git documentation

If no <pathspec> is given when -A option is used, all files in the entire working tree are updated (old versions of Git used to limit the update to the current directory and its subdirectories).

One thing that I would add is that if the --interactive or -p mode is used then git add will behave as if the update (-u) flag was used and not add new files.

I hate the staging mechanism of git, which can not be found in other SCM tools. So I always use:

\git add --all && \git commit --all

(Even though with \git add --all, \git commit is enough)

for add:

--no-ignore-removal  --all     | add, modify, and remove index entries to match the working tree
--ignore-removal     --no-all  | add, modify             index entries to match the working tree

--intent-to-add                | add an entry for the path to the index,  with no content

-A is short for --all

git add <pathspec> equals to:

for version 2.35.1 of Git: git add --all <pathspec>
Older versions of Git: git add --no-all <pathspec>

But git add followed by nothing, does not equal to git add --all, and will do nothing:

git add --all(omitting <pathspec>): handle all files in the entire working tree (old versions of Git used to limit the update to the current directory and its subdirectories).

git commit --all

Tell the command to automatically stage files that have been modified and deleted,. new files you have not told Git about are not affected