This isn't a new concept, so I'm sure it's been written about several times before. Just to be clear though, the writing and the thoughts expressed here are my own.
I like what you've done with your setup. I think you might be conflating the idea of a merge request template with a commit message though. What you described is a process of formatting commit messages in a standard way and then automating changelog generation, which is incredibly important too.
For something like that, I like to use a combination of Commitizen, Commitlint, Husky, and Standard Version.
Commitizen is a CLI tool that walks you through writing the commit message and creates the commit message in the right format following Conventional Commits.
Commitlint does what its name implies, lints the commit message to ensure it follows the rules.
Husky is used to run git hooks, so you can run Commitlint prior to allowing someone to finish committing their code.
And then Standard Version helps with semantic versioning and releases and automatically generates a changelog for you based on the commit messages.
This isn't a new concept, so I'm sure it's been written about several times before. Just to be clear though, the writing and the thoughts expressed here are my own.
I'm sure it is, though I'm sure I also saw, maybe a few months ago, the exact same checklist, and I swear it was on Dev. I thought you'd perhaps bumped the post by editing etc (rather than it being someone else's post).
I think you might be conflating the idea of a merge request template with a commit message though.
Not really, our setup is that the last commit message on the branch is the merge request default message (standard approach, and the merge message can easily be edited).
At the moment, I prefer not to set hard rules around commit/merge messages, because ultimately, there's no real buisness value to it. Our customers won't benefit because a commit message takes 10mins to write, for example.
Though if anything, I envy those who can take 30mins or so to craft commit/merge messages. I've worked in laid back environments like that before, and now, granted, my role means I'm rarely actually writing code.
Overall though, thanks for posting - it was seeing that checklist that prompted me to put in the change to our build process.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This isn't a new concept, so I'm sure it's been written about several times before. Just to be clear though, the writing and the thoughts expressed here are my own.
I like what you've done with your setup. I think you might be conflating the idea of a merge request template with a commit message though. What you described is a process of formatting commit messages in a standard way and then automating changelog generation, which is incredibly important too.
For something like that, I like to use a combination of Commitizen, Commitlint, Husky, and Standard Version.
Commitizen is a CLI tool that walks you through writing the commit message and creates the commit message in the right format following Conventional Commits.
Commitlint does what its name implies, lints the commit message to ensure it follows the rules.
Husky is used to run git hooks, so you can run Commitlint prior to allowing someone to finish committing their code.
And then Standard Version helps with semantic versioning and releases and automatically generates a changelog for you based on the commit messages.
I wrote about that here if you or anyone else is interested: medium.com/better-programming/thin...
I'm sure it is, though I'm sure I also saw, maybe a few months ago, the exact same checklist, and I swear it was on Dev. I thought you'd perhaps bumped the post by editing etc (rather than it being someone else's post).
Not really, our setup is that the last commit message on the branch is the merge request default message (standard approach, and the merge message can easily be edited).
At the moment, I prefer not to set hard rules around commit/merge messages, because ultimately, there's no real buisness value to it. Our customers won't benefit because a commit message takes 10mins to write, for example.
Though if anything, I envy those who can take 30mins or so to craft commit/merge messages. I've worked in laid back environments like that before, and now, granted, my role means I'm rarely actually writing code.
Overall though, thanks for posting - it was seeing that checklist that prompted me to put in the change to our build process.