tags:

views:

112

answers:

5

I'm finding myself using it each time before a commit. Is it right? If so, it should be the same command...

+1  A: 

Use it any time you add a file, or resolve a conflict. You don't need to use it if you just change a file, delete a file, or things of that nature.

jer
+3  A: 

There's git commit -a which is like git add -- it adds all modified files, but it does not add untracked files.

But yes, in most workflows, you will either git add before you git commit, or you will mostly use git commit -a.

Mark Rushakoff
A: 

Only use git add when you have new files that are not in source control. Otherwise, just make good use of the -a switch when using git commit.

Chris
I wont downvote, but I think that's horrible advice. One of the great features of git is the index/staging area. I'd suggest making good use of that instead.
camh
@camh: unless you don't need or want the staging area. It's indispensable when I need it, but the vast vast majority of the time I just want to commit. @Chris's advice is just fine.
kubi
+1  A: 

I use git add when I think a file is ready to be committed, even if I know I won't make the commit until some time later. All else apart, git diff reports on the differences between what is in the index (staging area) and what is out in the working directory. Once you've added a file, you don't see differences in it until you modify it again. So, if I have a number of files out, I add them to the index piecemeal, finally committing when all the changed files are ready. As a result, I seldom actually use git commit -a. However, each to their own. Both methods work, and git is kind enough not to force anyone to work the way it wants (within limits) - rather, it lets you work the way you want.

Jonathan Leffler
+3  A: 

git add lets you stage your commit in pieces. That's not always necessary if you're committing in properly sized chunks but some times it's inevitable.

It also makes it possible to preview a commit. When you use git add the files are checked in to your local index, which is separate from your working directory. When you then use gitk --all, for example, your index appears as any other commit node and you can see the effects of all your changes as you would a normal commit, before actually committing it to the branch.

What I find extremely useful is git add -i, which goes into interactive mode. You can also use git commit --interactive. Here you can choose which files to add (and even which pieces of your changes to the file to add) one by one, checking the differences for each.

There's no reason to use the commands independently if you don't want to, but there is definitely merit in keeping the commands independent of each other since they do different things and some people like being able to modify their working index without committing.

Mark Peters