I kind of maintain a balance here. I push neither too many small commits nor one huge commit. I break down the whole task into smaller milestones and as I reach these milestones I commit & push.

I like small commits, more commits approach. But then rebase your branch and merge one big commit.

While working on a feature branch of my own, I usually push commits frequently. This way, rolling back on a buggy commit is really easy and less work is lost.

But, before I merge into master or a staging branch, I usually squash these smaller commits into larger ones that semantically makes sense before merging, just to avoid too many commits in the commit history for master.

Small commits (without squashing) makes for a more effective 'git bisect', should you ever need to trace a bug down to a single commit. Note that every commit should pass the project's test suite. There's nothing sweeter than tracing a regression down to a single line of code using git bisect!