Could you say how many commits the repositories you usually work with have altogether? I don't know, probably hundreds of thousands. Furthermore, most of them have a message that will never be read, but if you need to navigate the history. I ensure you will thank a clear structure with a concrete and explicit statement describing the commit purpose.
How do you write a commit?
What rules do you usually enforce while writing a commit message? Have you checked if all people on your team follow the same? And what about developers within your company or your tech stack community? I had never thought about this topic until I needed to navigate git history and package release looking for compatibility issues.
Of course, this is not something I invented or that only happened to me. If you have good versioning following SemVer supported by clear commit messages, you can easily detect breaking changes affecting a bug at first sight.
Let's agree on how to write a commit message
Based on the Angular community commit guidelines, we have Convetional Commits, a simple yet powerful specification to write clear messages for both automated tools and humans. I already talked about it in my last post:
The idea is to have three sections within the commit headline and then a body and a footer of the message:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Please go and read the examples. You will notice how natural it feels.
Top comments (0)