I tend to commit as you propose: a commit is a logically connected change set. My commits can be anything from a one-liner to a change in all files (for example add/change a copyright notice in the source files). The reason for change need not be a full task that I am implementing, but it is usually a milestone in the task.

If I have modified something that is not related to my current commit, I tend to do an interactive add to separate out the unrelated changes, too - even when it is a whitespace tidy up.

I have found that commits that simply dump the working state to repository makes them a lot less useful: I cannot backport a bugfix to an earlier version or include a utility functionality in another branch easily if the commits are all over the place.

One alternative to this approach is using a lot of tiny commits inside a feature branch, and once the whole feature is done, do heavy history rewriting to tidy up the commits into a logical structure. But I find this approach to be a time waster.

The way that Git recommends that committing be done is such that each change is an atomic, logical commit. In other words, it represents one logical change (executed well) and the entire testsuite passes both before and after the change.

One situation in which adding and committing may be done separately is when you're working on perfecting a commit. You may have an initial version of your code which works, but is messy or still has debugging code in it. You can add this change to the index using git add while continuing to refine it in your work tree. If you find that you've broken things, you can roll back to the version in the index and try again. On the other hand, if you find that a change is better, you can add it again, until you're finally ready to commit.

Another, equally valid workflow for this situation is to make multiple commits, one each time the change is an improvement over the last, and then squash them together using git rebase -i or git reset --soft. Which you want to do depends on your preferred development style; they will essentially both produce the same result.

An alternative situation you may want to use git add separately from git commit is when you want to stash only some changes. You can use git add to keep the changes you want in your working tree and then git stash --keep-index to stash the rest of them away.

A question which you didn't ask but which might be on your mind is why the two functions are separate. This is because sometimes when developing you end up with changes from multiple logical commits in your tree and you want to commit only part of them at once, making additional commits for additional logical changes. Being able to add only part of the changes at once means you can commit those, and then add more changes and commit them, and so on.