• “progress on [1], fixed linting [2]”
• “[1] completed, setup for [2]”
• “[3] and [4] completed”
• “fixed formatting”
• “refactoring [1] and [2]”
• “fix variable typos”
• “update logic in [2]”
• “revert package.json and regenerate package-lock”

All my commits have comments. I generally commit after completing a ‘block’ objective, a describe what that was but in very simple terms mostly in regards to the file/section with the most significant logic changes. I don’t always specify the file if I did tiny typos/linting/annotation across a bunch of them, because the logic is unaffected I know that the differences will be visible in the commit history.

My weakness is that I don’t do it often enough. If I’m working on [2] for several hours, I’ll only commit when I consider it minimally-viable (completed 2), or when moving between machines ([further] progress on 2). And I have a bad habit of not pushing every time I commit, just at the end of the day or when moving between machines (though a messy rebase hopefully made that lesson stick), or if somebody else on the team wants to review an issue I’m having.