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:
![juanvegadev](https://res.cloudinary.com/practicaldev/image/fetch/s--oMqzlXe_--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://res.cloudinary.com/practicaldev/image/fetch/s--oZ_R_q4F--/c_fill%2Cf_auto%2Cfl_progressive%2Ch_150%2Cq_auto%2Cw_150/https://dev-to-uploads.s3.amazonaws.com/uploads/user/profile_image/141711/add58eef-3934-4b7a-87c1-ab9043a287be.jpg)
Configure the release of your golang module with Github Actions
Juan Vega ・ Oct 9 ・ 2 min read
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)