I typically commit at least once an hour when I'm coding full steam ahead. My rule is I commit to my local repo whenever I have uncommitted work that I'd care about losing (if I made a blunder and had to revert everything). I also commit locally whenever I switch tasks (so one commit is one coherent block of work). I only push from my local to central repo when I have the code in a reasonable "working" state.

If you're working on your own then commiting frequently is fine. If you are working with a team then that's a lot of information for your colleagues to process, so it's a good idea to condense your changes down a bit when you commit to the main branch. I think that's what the article is getting at when it talks about feature branches.

Commits should be as small as possible, but not break anything.

With git the more important questions: When do you push?

Not as often as possible. I repeatedly regret a push, because i need to commit a revert/change commit afterwards. If i had waited, this could have been cleaned up before pushing.