31–40 of 294 posts
However, actually writing a good commit message is an art form few have mastered.
I wrote a small natural language linter to teach my teams meaningful technical writing: https://github.com/codingjoe/word-weasel
Odd. The main reason to use this style of commit message is for CI/CD automation. EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies. The type of the commit informs the automated workflows how to handle the commit. This is why it comes first. For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version num…
I see more of these conventional commit-style comments recently and it feels like coming from Claude Code etc. It's a bit unsettling that not only training data but also random lines in the default system prompt affects this kind of software development norms in subtle and pervasive ways.
My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…
My main complaint with conventional commits always was that they don't include an issue number in the commit title. It's not even mentioned in their standards as optional or something. To me this is almost the most important information in a commit message. I don't know how often in the last 15 years I was cross checking the issue description referenced by some old commit to get the full context of a change. I also f…
Why do you even want the issue number in the commit title ? I find that super annoying and unfortunately GitHub kind of forces it on you if you use merge queues. It's fine for it to be in the description.
The author's example of a conventional commit is not correct anyway IMO, which is maybe why they think the "fix" part is redundant: > fix: prevent foo from bar'ing The whole idea of conventional commit is: > fix: [problem] so the correct conventional commit would be: > fix: foo bar'ing which is succinct and perfectly fine.
What you describe doesn’t match https://www.conventionalcommits.org/en/v1.0.0/ >’s examples, or any practice I’ve ever seen. > fix: prevent racing of requests Though the example in the actual specification, “fix: array parsing issue when multiple spaces were contained in string”, is more inconclusive (and frankly doesn’t really make sense as a description ).
# Bug Fixes
- foo bar'ing