Score:13

Ubuntu

What is the difference between git add * and git add .?

vico

3/12/23, 12:28 PM

What is the difference between commands git add * and git add . when I put parameters * and . accordingly? What list of files system returns in both cases?

1940

0 + 0

command-line

git

eis

3/14/23, 9:26 AM

See: [stackoverflow: git add * (asterisk) vs git add . (period)](https://stackoverflow.com/questions/26042390/git-add-asterisk-vs-git-add-period)

Thorbjørn Ravn Andersen

3/14/23, 1:42 PM

This depends on which command interpreter you use to execute git from.

Score:32

Ubuntu

Dan

3/12/23, 12:41 PM

* is a bash glob. It will expand to all files in the directory you're in, excluding dotfiles (files that start with a dot (.)).
. means the current directory.

The result can be quite different depending on the content of your directory and if you have a .gitignore file.

Consider you have the following files and directories in your directory:

.dotfile-that-must-be-committed
.git/
.gitignore
some-file-that-is-in-gitignore
some-other-file

When you run git add *, the glob is expanded before the git command runs. So what the git command receives is the following:

git add some-file-that-is-in-gitignore some-other-file

This causes four problems here.

Git will complain that some-file-that-is-in-gitignore cannot be added and will ask you to add the force (-f) argument if you really want to add it.
both .dotfile-that-must-be-committed and .gitignore were not added as * does not expand to dotfiles.
If you have deleted files in the directory you are in, * can never expand to those, so deleted files will not get staged.
If you have renamed files in the directory you are in, * can never expand to the old name but it will expand to the new one. So what git will see is that you added a new file, and since the old name did not get staged you will end up with the same file existing twice, with the old name and the new name.

However, running git add . tells git to add the current directory you're in without specifying which file to add. In this case, git will check the .gitignore file and recursively add all files not mentioned in .gitignore.

In summary:

You should use git add . not git add *.

Even better:

Use git add full/file/paths so you don't add stuff by mistake that isn't ready to be added.

And even much better:

Use git add -p to review your changes and pick and choose which patches you want to be added.

0 + 0

Roger Lipscombe

3/13/23, 12:41 AM

Even better: `git add be/explicit`. You should use neither `git add *` nor `git add .`, because you should be much more deliberate about what you're adding to git.

Jörg W Mittag

3/13/23, 9:31 AM

While I am personally a huge fan ofu `git add -p` and use it all the time, it should be noted that there is a big danger associated with it, namely that you are staging a state that has never, ever existed in this form on disk, and thus likely never, ever been tested. For this reason, it is banned in some Git usage guides in some organizations.

John C

3/13/23, 3:15 PM

I also agree with using `git add .`, but will note that it's the current directory and downwards - so if you happen to be down in a subdir (say, at the command-line, not a GUI tool), you wouldn't add any changes in up-level directories. I tend to do a `git status` next, just to make sure I didn't miss anything.

David Z

3/13/23, 10:40 PM

@JörgWMittag Interesting... although I would argue that the danger only arises if you don't go back and test the resulting commit. Doing that test is an entirely reasonable thing to do and to expect of people. So, personally, I disagree that it should be noted; I think it would be more of a distraction than it's worth to add that to the answer.

eis

3/14/23, 9:29 AM

this answer is relatively long and still leaves out all the important stuff. the most important use cases for using dot are 1) all subdirectories and 2) all deletions/renames, which are not even mentioned here.

Dan

3/17/23, 11:36 AM

@eis You are right about the deletion/renames. I'll add details about those. But regarding subdirectories, `git add .` and `git add *` behave the same way for those as long as their name doesn't with a dot.

Score:3

Ubuntu

theonlygusti

3/14/23, 12:07 AM

Something else not pointed out by current answers would be that git add * will not notice if you've deleted or renamed any files, but git add . will.

0 + 0

Score:2

Ubuntu

Someone

3/12/23, 12:42 PM

Short Summary

git add * means add all files in the current directory, except for files whose name begin with a dot. This is your shell functionality and Git only ever receives a list of files.

git add . has no special meaning in your shell, and thus Git adds the entire directory recursively, which is almost the same, but including files whose names begin with a dot.

_{Answer adapted from stackoverflow}