When writing commit messages, we have a lot of flexiblity. We can write the largest commit message
that the world has seen until then or we can do a git commit -m "wip" and that’s it.
Writing commit messages takes a lot of practice, no doubt. There are guides, patterns and all that stuff around the internet. One example are Conventional Commits. Conventions and standards are good, at least most of the times. However, I’m not sure if this is the case with conventional commits.
If you are unfamiliar with it, here’s the quote from their page:
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with > SemVer, by describing the features, fixes, and breaking changes made in commit messages.
The commit message should be structured as follows:
<type>[optional scope]: <description> [optional body] [optional footer(s)]
Sounds easy, right? Now we have a type, a scope and that’s it. And the types are fix, feat,
refactor and some else. That’s not a lot of new concepts, nice! I’ve adopted Conventional Commits
around 2021 and have been using them since.
Simplicity does not exist.
Although it sounds easy to prefix your commit messages with a type, that part of categorization is actually hard. At least for me.
Example: Updating a major flaw in the docs
There’s a major problem with the docs, they’re out of date and they written behaviour leads to
unexpected results. Let’s assume that the commit actually solves this problem. Because it’s going to
fix the instructions for new users, it’s probably a fix. Maybe even a fix(docs). Or does it
belong to the docs scope? It could even be a chore.
It depends on the personal perception of the issue severity. I wouldn’t judge anyone for picking the wrong scope.
Guidelines, Jasmin, guidelines!
Yes, of course, there should be a guideline for the team. But even then, writing good commit
messages is hard. git itself is a monster. No one should deal with git. I understand it very
well (at least I think so). I’m working years with this thing. I’m no longer “deleting and
re-cloning” repositories, just because I broke something. Nevertheless, it’s still a shitty
software. It works, but it’s definitely not user-friendly.
But what about the automation?
Actually I don’t think that autogenerated changelogs are useful. If your changelog is just a
categorization of your commits, it does not provide any value to me. I don’t care about the hundreds
and thousands commits by @dependabot. Either admit that you don’t want to write a changelog or
write one. Yes, it’s work. Yes, it’s annoying. But it needs to be done.
And now?
Actually, I don’t have a proper solution for writing commits. But I know that I won’t be writing
Conventional Commits much longer than needed. Instead, I use the good ol’ style: regular titles.
Instead of feat: add new menu button I’m going to write Add new menu button. And I’ll put more
effort into my changelogs.