To all the people saying "commit only when you have a useful, well thought out message to write, and when your feature is 100% complete, and you have unit tests for it", I say: You're still in the SVN mindset.
If you're using git, this is what I would call a smart workflow:
- Commit as often as you like. Write any old quick message there. No one will see it anyways.
- After say, 10 commits, you've finished that feature you were working on. Now write tests and commit those tests. Or whatever else you want. If you like TDD, write tests first, I don't care, neither does git.
git rebase -i from the first 'messy' commit you added and fix your local history by squashing, editing, omitting and otherwise cleaning up your recent history into logical, clean commits with nice messages.
- After cleanup, ask someone to pull from you.
- Rinse and repeat.
Notice that step 3 is when you end up with those nice commits you were after, and that using SVN you'd have to abstain from committing until you've done the first two steps, which is what most of the other answers are suggesting. IOW, you don't want to inflict your half-written, untested code on others, so you don't commit for a week, until your feature is done. You're not using version control to its full potential.
Also note that anywhere between steps 1 and 3, you can
git push your changes to your own private repo mirror on the server to get free backups if your laptop HDD dies.