One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)
Yes, definitely nice if you can make your commits atomic changes. The more easily able to right a nice summary line (50 chars please!) the better.
On the other hand, some changes are big and messy. In this case I sometimes do intermediate commits, especially if it's at the end of a day just so I can keep yesterdays changes conceptually separate from todays. In the end I may rebase -i the whole thing and clean things up before pushing, but only if there are some obvious and quick ways to split it up.
I tend to do a lot of work upfront (without committing) and then go back and split the work up into smaller commits with "git add -p". I commit often, so it's never a huge list of changes I have to split.
I do this so I can cherry pick commits into other branches (e.g., fixing a bug in my current branch and merging it back to master).
It's really a judgement call, although I'd definitely recommend against committing every single save. The only hard-fast rule I follow is to always commit whatever I have left-over at the end of the day, so that I never lose work overnight or over a weekend.
Other than that, if you felt like you've taken a decently-sized chunk out of whatever problem or feature you're currently working on, commit.
I think you are confusing committing with pushing? But even then, I do not see any harm in pushing often, you can always amend your commits before final merge or pull request.
I try to commit when I have made enough changes so that builds and functionality don't break but not everything is 100% done either. My commit comment will describe what I was doing and what I changed. If unit tests pass then I think it's fine to commit (if you aren't writing unit tests than I advise that you should). There are projects I have to share with other developers and projects that I am the only developer on and I keep my rule of committing the same for both.
I tend to commit the first set of written tests, the first code & test fixes that passes them, etc. It's very organic though; if you do a "write one test pass one test" workflow that'd be a lot, but since I tend to work on multiple tests at once, it works fine.