Commit message rules encourage squashing commits
I'm back in the GitLab workflow after working outside of it for couple years (time flies!) and I was suprised by the Danger Bot rules when submitted MRs.
The commit subject must start with a capital letter.
The commit subject must not end with a period.
The commit body must not contain more than 72 characters per line.
The commit subject and body must be separated by a blank line.
These are stylistic and I generally agree with, but I think we should figure out a way to automate that process.
The commit subject should ideally contain up to 50 characters, and must not be longer than 72 characters.
I think if we should stick with 72 chars max across so it is easier to setup/automate in whatever editor we use.
Commits that change 30 or more lines across at least 3 files must describe these changes in the commit body.
The merge request must not contain more than 10 commit messages.
These two are in my opinion the most problematic — the basically go against each other. Typically, I try to work in increments over a feature and commit when I reach whatever techinical milestone I want to "checkpoint" at. It can also be out of the need to expose some idea or architecture and push it.
I'm an avid proponent of rebasing and squashing commits but having to describe changes in every functional commit seems a bit over the top when it comes to incremental changes.
Consider the following git history:
WIP: Trying out the ranking algorithm WIP: Improve the results ordering Fix a failing test Revert back to a simpler ranking algorithm Refactor the search code as a finder Improve documentation Add tests
What happens here is that we encourage developers to squash all of these to comply with the rules, instead of keeping the history around. It is the quickest way to comply.
commit bb9ce5eeafcfab3be4c035b81c9fb76a1d772d85 (HEAD -> compliance) Author: mbergeron <firstname.lastname@example.org> Date: Thu Apr 9 10:55:57 2020 -0400 Improve the search algorithm We now use a better ranking algorithm so that results are displayed by relevance
Having good commit messages is really important, but that doesn't mean having less commits in my opinion. I'm looking for some insights about why we have these rules.
I think this goes against the Keep It Simple mentality and the Low Level Of Shame that we should have when we contribute.
Feel free to chime in!