Conventional Commits

Conventional Commits aims at producing efficient and easy to understand by both humans and automated tools commit messages. While it is mainly focused on git, it can be adopted by any source control management system that is based on commiting changes. The idea is interesting, and at glance remembered me the Semantic Versioning approach, and in fact Conventional Commits keep into account the Semantic Versioning. While I don’t adopt the Conventional Commits approach, and I don’t think I will in the near future, I like the idea of having a convention that can make order out of caos. In fact, one problem I see when working with other people, is that the commit messages are often written in a rush or without enough details. Every time I teach git, I say that a commit is a part of documentation and hence it must be detailed (but not bloated). In this sense, the Conventional Commits specification helps in getting the same approach in writing commit messages, and there is linter to help commiters verify the quality of their commit messages. So far, I’ve seen most often artificial intelligence generated commits using this convention than human beings! I don’t like the format of the commit message as specified by the convention, so I don’t see my commits having always fix, feat and prefixes like that. They look less readable to me than a well written commit first line. On the other hand, adding to a commit message some tags (e.g., BREAKING_CHANGE) sounds good to me and is easily automatizable. Clearly the convention tries to make the --oneline commit log emphasizing the content of the commit itself, and I think this could lead to committers not writing appropriate documentation and commit description. As usual, time will tell us if this is really good or not. The real added value, according to me, so far is that committers will adhere to a standard.