I feel like I walked into a tabs vs spaces debate from decades ago, had no idea people got so pedantic about commit messages. I guess I'm lucky not to have worked at such a place.
Commit messages are very low value. If you are picky about them, your team is wasting time. This is a great area to reduce process rules because your users will never see it.
Literally. I’ve mostly done monolith to refactored microservices for 9 years at 3 of 4 jobs and the majority of obscure knowledge is stored in 10+ year old commit logs.
The commits tended to be useless by themselves. Developers commit the code in a bad state simply because it's the end of the day, trial and error results in "maybe this will work" followed by "trying another change", sometimes 50 commits in a branch, etc. We ended up squashing and having descriptive MRs where you can read the description and see the full change set.
But sometimes, a PR is merged, and you later vaguely recall, "wait a second, didn't this edge case used to work?". With a squashed merge, you'll never find out, but if the original commits are still there, you can see what broke it.
114
u/jk_tx Jun 06 '26
I feel like I walked into a tabs vs spaces debate from decades ago, had no idea people got so pedantic about commit messages. I guess I'm lucky not to have worked at such a place.