Many orgs have some sort of "standard" for writing commit messages. (It matters not whether you're using git, hg or something else for your version control.)
The first line of the commit message is what will show up in most summaries of commit history, and additional lines (assuming your VCS supports this; most do) only show up when you drill a little deeper.
I prefix the first line with a single-letter classifier: Every commit is one of
C -- Configuration change. And that's project or build process or CI configuration.
R -- Refactoring. Do I need to tell you that this means no functionality changed, only how something got done?
A -- The architecture got changed. Something in the large-scale structure of the codebase.
F -- Feature. We added or changed something that the users of the software will feel/see.
T -- Tidy. We're just tidying. Read Kent Beck's Code Tidy story for more detail.
CRAFT. You can hear what it means to me. Every commit is one and only one of these. Don't mix up different kinds of change in a single commit.
After that first initial line prefixed with one of the letters [CRAFT] I might add paragraphs of prose detailing the whys and wherefores of the change, the doubts I harbour and tradeoffs I'm making, but that's a whole other story.
If you think you can't fit a single commit into just one of those categories, you're almost certainly making the commit/change too big. Many More Much Smaller Steps, my friends. No! Smaller than that, even...