I tend to do a lot of commits. I try to keep each commit focused on a single task. So, for instance, if I need to add error handling to something and improve the output formatting, that's two commits. I would work on one, commit it when it is working, and then work on the next thing. I feel like a commit should be a single, descriptive line and should describe a single code addition or modification. Just my personal approach.

Committing and pushing acts partly as a form of backup for me, but when merging to something like a sprint branch I try to squash those commits so that the history is more about features than tiny changes.

The first line of my commits describes what the change will be once it's applied, and I try to keep these pretty well defined and under 100 chars or so.

That means there's a nice semantic limit on how much a commit can do, so while a single commit might add 100 media files or even reprettify the whole codebase, I'd split it up if it was doing two things that I couldn't fully describe in two short sentences.

I commit every time I made a change and the application is still working properly, that way I can go back to a previous version that is working well if something go wrong.

I like to treat commits as the end of a task. I split a feature or bugfix into very small, actionable tasks, like creating a new entity,creating or refactoring a function,implementing or updating a new dependency, etc. Each one of those tasks will be a single commit, as it allows me to roll back to any point in time, and this atomicity also helps keep concise and clear commit messages, as only a few lines change, so it's easy to describe what the commit does in a few characters.

Once the feature is done or the bug is fixed, I squash rebase onto dev/master, keeping the feature/hotfix branch for the commits history for faster searching.