jasmins little space

Why I think that Conventional Commits are a bad idea

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.