tags:

views:

241

answers:

5

As a git noob trying it out on a Rails project, I am wondering if it is bad practice to do git add . (add current directory) before every commit. The intro tutorials I have seen show adding the current directory initially, then using git add new_file to add files after that. If I'm adding a bunch of files from a bunch of different directories, this seems too hard.

Essentially, if you are adding more than one or two files, is it OK to use git add . every time I want to commit? Is using git add . the same as explicitly doing git add new_file for every file that has been created since the last commit?

+2  A: 

Maybe git-commit -a does what you want? It will stage and commit all modified and/or deleted files which are under version control.

yawn
+2  A: 

you can use git commit -a to commit all changes to files already under sourcecontrol (this is like subversion’s commit command)

knittl
+2  A: 

git add . will add everything that's in the heirarchy, including new files. If you want to track all files that are in the directory, this is fine.

Another (perhaps more common) usage is to do git commit -a, which adds only the files that changed since the last commit before committing, and doesn't include any new files.

EDIT: git add . won't remove any files that were deleted since the last commit. If you're deleting files, I'd use git rm <myfile> so that git is informed of the removed file, and you don't forget to make sure git knows it was deleted. As mentioned in another comment, git commit -a will notice files that have been deleted.

James Cassell
Thanks James. So it is not inefficient or redundant to use `git add .` as opposed to explicitly adding files individually? It's not bad to "re-add" files that have already been added?
Nick Stamas
"re-adding" a file that hasn't changed has no effect on anything, so no, it isn't bad.I don't know about inefficient -- <code>git add .</code> is instantaneous when I use it, but I don't know if that remains the case in a large folder heirarchy.
James Cassell
However, `git add .` will add files that probably shouldn't be, like editor backups and random other ephemeral cruft.
Novelocrat
A: 

Also, you might appreciate the interactive mode ('git add -i'), which can speed things up if you need to selectively add a bunch of files. You can see it in action in this GitCast.

ewall
+6  A: 

There's nothing wrong with using "git add ." if your .gitignore is up to date and you are sure it won't add anything that you don't intend to track. Do a "git status" first to check this.

I wouldn't recommend doing this before every commit, though, as most of the time (at least for most use cases) you will be modifying existing files and only adding one or two completely new files. In these cases, "git add -u" and "git add <file>" are often less work as with "git add ." or "git add -A" you always need to check that you're not accidentally adding new files that were actually temporary files and which should have been ignored or deleted.

"git add ." would be most useful where you know that you've added many new files in the hierarchy starting at the current directory and don't want to specify them all explicitly. You need to be sure that everything that you don't want to add is correctly ignored.

Charles Bailey