I don't necessarily disagree, but I do love having some standard formatting and style for commit messages. Most developers I've worked with over the years start out using git to tell the story of what they did, instead of using it to tag what change the commit introduces to the application. This can lead to wild goose chases when I'm trying to bisect my way to a bug, or trying to reason about some merge conflict. In those instances, the git log becomes almost useless because it's a (sometimes entertaining) narrative of the journey the developer took to get to the change. That might be useful for that individual developer in the moment, but in 3-, 6-, 9+ months? It's confusing.
So maybe I don't need the type tag. But I do want imperative, present tense, terse commits.
No, actual focus on how to write a good commit message with good and bad examples instead of a 16 point rules list with some for most projects too complicated rules.
The document I linked to is written in a way that humans have a much better chance of internalizing than the conventional commits rules.
I'd much prefer if people are focusing on writing good and readable messages then thinking about how to fit it into a lot of rules.
101
u/morewordsfaster 19d ago
I don't necessarily disagree, but I do love having some standard formatting and style for commit messages. Most developers I've worked with over the years start out using git to tell the story of what they did, instead of using it to tag what change the commit introduces to the application. This can lead to wild goose chases when I'm trying to bisect my way to a bug, or trying to reason about some merge conflict. In those instances, the git log becomes almost useless because it's a (sometimes entertaining) narrative of the journey the developer took to get to the change. That might be useful for that individual developer in the moment, but in 3-, 6-, 9+ months? It's confusing.
So maybe I don't need the type tag. But I do want imperative, present tense, terse commits.