Thomas Anderson <zelnaga@xxxxxxxxx> writes: > 1. When do you commit changes and when do you stage changes? Or maybe > more to the point, what's the difference between doing "stage, commit, > stage, commit" and "stage, stage, commit"? "git add file" is a way to let you say "I have examined the changes since the last commit to this file, and I do not want to see them in the output from my later invocations of 'git diff'". The intent is to let you focus on one detail without getting distracted by other changes. So typically you repeat the following steps: - change your files in the working tree; - run 'git diff' to check your progress _incrementally_; and - run 'git add that-file' to mark that the changes so far is satisfactory. "add then commit" would be just running the above cycle once between commits. "add, add then commit" would be running the cycle twice. This doesn't help you very much when you are always making small commits. You might never encounter a case where you need to do more than one cycle of the above before creating a commit. But in real-life, the extent of changes that need to be contained in a single logically independent unit you would want to record as a commit is sometimes large enough that it helps to be able to work incrementally. Also often people keep small changes that they do not want to commit yet in their working tree (and of course they never say "git add" on them until they are ready). If you are interested, you can read more on this: http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476 Other times, you can always do "commit -a". Also, all of the above doesn't really matter in projects that tolerate incoherent and/or unfocused commits, as they do not care how well you choose commit boundaries. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html