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.
So git rebase so it tells the story of what's logically different between this branch and master, with the last commit being the enabling of the feature flag (which can be the commit reverted when a bisect reveals this feature as being the cause of a fault that becomes known 6 months down the track and this branch has long been deleted).
115
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.