Being overly consistent with your git commits is great for your side projects and your team. For similar reasons, you are styling and formatting your code consistently (hopefully). And for the same reason, you sometimes add purposeful comments to your code.
In a recent episode of the YAGNI podcast, the speakers were bashing against these archaic rules that can be found all over the Internet:
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
There was an argument saying that apart from point 7, all the others are not that important. You could easily drop some or most of them.
But imagine the wild west of trying to read through a git log history before there were any conventions around this.
I learned git with exactly these rules and I can only say that they benefited me in not having to think about how I should write my messages because I exactly knew how. Now it was just on me to get point 7 right and right valuable stuff in the body and in the subject line.
It's much easier to digest uniformly written short commit messages in the GitHub list:
I'm almost always working on different projects simultaneously and getting into a codebase after a couple of weeks is much easier when I read through the latest commit messages to remind myself where I was a couple of weeks ago and what needs to be done next.
Sometimes there's a WIP commit at the top:
This way I know that I can soft reset my branch to the commit before that and continue finishing this commit (I know what's TODO because the text after WIP - will tell me what the goal of this commit originally was). Win-win.
All of this is much harder if your commit history looks like this:
* fix - Rudolph Wanngerhagen
* implememtn feedback - Jammo Mizin
* Implement turbo loader for widget. - nickname14
* changes for shopping list - Baran Mucho
* refactorings of bubble tea shops wi..- Baran Mucho
* Bump Rails version to 6.1. - nickname14
And in 2022 this is often still the case in bigger teams where a variety of team members are all rolling their own message styles. It's hard to read and hard to trace what happened. Lose-lose.
I don't mind too much because life goes on and those projects float on just fine too. It just makes things a bit harder on ourselves, which isn't necessary imo ;))
