Are conventional commits worth it?
For some time, I've written commit messages following the Conventional Commits specification, where you start the subject with the type of commit - such as feat, fix, chore, docs, etc - and provide an optional scope before completing the subject line (the first line in the message).
Then, it is encouraged to add a longer body to the message and provide any links and task IDs that the change relates to.
Now I've been using it for a while, I'm deciding whether it adds value for me and whether it's worth me using it.
I don't create automatic CHANGELOG files from the commit types.
The scopes are usually arbitrary, it's unclear which scope (or scopes) should be added, or it repeats the module name I'm working on (which I could see from the Git diff).
While I see value in writing descriptive commit messages, I'm unsure if I do to format the subject line in this way.
Here's the thing
I like to use an iterative approach to my workflow. I like to try things and see if they work for me. If not, I can stop or continue iterating.
If working with others, should you focus on writing commits that categorise commit messages within their subject or writing descriptive commit messages that capture why the change is needed?
Which provides the most value when looking back at the Git log in the future?
- Oliver
