A bad commit (that one of my coworkers always does) is "update file.ext". Says nothing other than the name of the file that was updated, which ends up with tons of repeat commit messages for common files and provides zero info that wasn't already included in the commit itself.

Another poor commit is a description like "adds padding". It's a little too vague and doesn't really tell you much that wasn't already apparent by looking at the change itself.

A better commit might be something more like "Add variable padding to ProductLogo component, fixing logo overflows for issue#78". It summarizes the change, the intended outcome of the change, the reason for the change and a reference to an issue all in one short sentence.

You don't have to go into overwhelming detail for every minor front end change but if you're intelligently tracking and squashing your commits writing them well can help a lot later on if you ever need to understand the context of an older commit or even a given line in the codebase.

Subjective and also depends on the culture where you work. I’ve worker at places where the majority of the “why” Is in a JIRA ticket, so the commit message better reference that ticket number. Not so at other places. See what I mean?

Or, just squash your commits and focus on bigger things.

As already mentioned: It depends.

But this might be a good start: https://www.conventionalcommits.org/en/v1.0.0/#summary

We've used this as a starting point and adapted it to our needs (E.g. some simplification, defining the possible values for scope, etc.)

Take a look at Wine's commit log. It's really well curated. https://github.com/wine-mirror/wine/commits/master