Conventional Commits encourages focus on the wrong things(sumnerevans.com) |
Conventional Commits encourages focus on the wrong things(sumnerevans.com) |
To some extent the "type" is simply about trying to limit/standardize the number of possible "verbs" to start a commit headline with, in which case Conventional Commits made the mistake of mixing verbs and nouns (fix and refactor are verbs but feature and chore are nouns) and adding distracting punctuation where English prefers none between the Verb and its direct object in a "Verb the thing" sentence. "Verb: the thing" only ever really looks awkward.
But also do we really want to limit the possible number of verbs that a headline sentence can start with when making commits? "Fix" and "Prevent" may often act like synonyms but there are connotative differences. In some cases "Prevent" may be a shorter way to explain why something needed to be fixed in a headline because "prevent" also says "stop a thing from happening that wasn't supposed to happen" whereas "fix" alone may not yield that extra context. The top line of a commit should be a short and sweet headline and sometimes the cleanest way to do that is to use the full gamut of English verbs at your disposal to tell the right story as quickly as possible.
And it’s ugly.
(But I suppose I am talking primarily about the first line part. The “BREAKING CHANGE” bit is potentially actually useful, though being incompatible with git-interpret-trailers despite leaning on git-interpret-trailers for other footers seems a bit crazy.)
My gripe about conventional commits is the redundancy: fix(ci): fix the foobar
> something like fix, feat, chore, docs, or refactor
'Docs' are also part of the program, they need fixes too, and features need docs. If the docs don't match the features because they're not being updated when the code is, the docs are a lie and waste other developers time.
Also if you were writing a standard: why would you randomly abbreviate 'feature' but not 'refactor'? That sounds like a nitpick but standards require great thought, this is a bit of a smell that there hasn't been much thought into designing 'conventional commits'.
Finally: the name 'Conventional commits' is a land grab (reminds me of when someone made a JS Standard and called it 'StandardJS', ignoring every existing popular standard). From the article, the *actual* convention is 'scope: work"
- Linux
subsystem: description
prefix: description
area: description
package: description
pkg-name: descriptionThis makes neovim plugin manager highlight the change differently which brings attention to it when you update stuff.
So please do use it instead of complaining!
I do like the suggestion of
scope!: ...
if it will be treated the same way with breaking changes reactions.
I'm not saying that conventional commits are God's given best way to structure a commit message, but they are a defined structure, and I find it much more effective and important that some expectations be set around commit messages, and I think conventional commits are as good as anything.
Like the author is making a big deal that they think scope is more important than type. I may tend to agree, but I think the difference between "fix(compiler)" and "compiler fix" is not exactly a hill I'd be willing to die on.
The tech industry has tons of things that became standards even if they weren't optimal. E.g. if one were starting from scratch I think any sane person would argue JSON should support comments (sorry but Douglas Crawford's rationale for not including comments never made sense to me), better defined numeric formats, etc. But it was better in many contexts than what came before it, so it became the standard. I could believe that there is some other format that differs a bit from conventional commits that is a little better, but not really better enough to want a whole other competing way of structuring comments.
I spent some time recently coming to the conclusion that I did not prefer CC, but wanting some reliable structure. In the end, I found I was coming up with convoluted schemes that were getting in the way of actually solving my real problems and just settled on the tried and true:
“When applied this commit will...”
- Add <functionality>
- Update <existing>
- Refactor <while keeping same boundary behavior>
- Remove <some subsystem or functionality>
- Cleanup <documentation or style>
In over 30 years of using source control, I've never once worked on something where it's useful to include the component (article calls it scope) in the description in a standardised way. It's obvious what components are affected based on where in the source tree the affected files are. Similarly "bug", "fix" or "feature" adds no useful value. It's important or it wouldn't be checked in.
The only thing I've found useful, and which the article doesn't even consider, is a link / id for the relevant change request. The commit already contains all the information about what was done in the change, what's missing is the context about why.
Even on my solo projects I include a JIRA reference in square brackets before the description. If it's just something I randomly decided to fix during the course of development, I'll create a short 1 line JIRA to get an id and explain the why there.
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 felt that this habit is kind of standard - until i had to learn about "conventional commits".
I never got the hype.
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
Cleaning my kitchen after a meal may be a chore, but it’s not an intrinsically bad or unpleasant experience most of the time, it’s just good hygiene and afterwards I have the satisfaction of things being clean. Not cleaning the kitchen feels way worse to me as it ultimately leads to other far more unpleasant situations.
Such it is with updating dependencies, it generally needs to be done, so it’s good to do it, but it’s in no way noteworthy, so chore describes it perfectly, to me it signals that: “it’s work that needed to be done, but not for a feature, functionality change or bug fix on this particular code base, so you’re unlikely to see much change”.
So now I associate it an automated pr vs authored
Same idea without the pejorative aspect.
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 number is incremented. If you commit a `feat: ` then it's a minor version is bump. `feat! ` is a major version bump.
Even if you're not using CD for releases, semantic commit messages are sometimes used to automate change log generation. Granted, your change logs should not typically include the Git commit messages themselves — those are developer facing, not user facing.
Ill add: I am personally put off in the same way your parent comment is, because hard stances are usually wrong, and I like a bit of nuance in my life.
Edit: Looks like they changed the title to be less provocative. Good for them
Mildly toxic was the same but worse in my opinion.
I don't like conventional commits much neither, but let the people use whatever they want!
There is a meme that inspires some of this genre of title, fwiw
A changelog is user-facing”
I'd say that ship has probably sailed. Most companies are happy with “Bug Fixes & Performance Improvements”. At least if they're not going to put the effort in, then a generated changelog is better than nothing.
Funny to ask to stop doing something I don't do or never even heard of. I typically only mark database schema migrations or other major things with special prefixes.
I fully recognise that it doesn't make sense for huge projects like the Linux kernel to do this. But for 99% of projects conventional commits combined with semver vastly improves the release process status quo and makes it easy to automate.
`git describe` is easy to automate for CD, but can leave version number decisions to people via `git tag` choices (and/or GitHub Releases) rather than trying to guess from commit history magic keywords.
ReleaseJet – Release notes from issue labels, no Conventional Commits - https://news.ycombinator.com/item?id=47847605 - April 2026 (1 comment)
Why Use Conventional Commits? - https://news.ycombinator.com/item?id=46940152 - Feb 2026 (1 comment)
Conventional Commits Considered Harmful - https://news.ycombinator.com/item?id=46019218 - Nov 2025 (1 comment)
Conventional Commits Considered Harmful - https://news.ycombinator.com/item?id=45420887 - Sept 2025 (1 comment)
Conventional Commits makes me sad - https://news.ycombinator.com/item?id=44482546 - July 2025 (2 comments)
A specification for adding human/machine readable meaning to commit messages - https://news.ycombinator.com/item?id=40740669 - June 2024 (2 comments)
A specification for adding human and machine readable meaning to commit messages - https://news.ycombinator.com/item?id=34660646 - Feb 2023 (48 comments)
Ask HN: Are you still using conventional commits? If not why not? - https://news.ycombinator.com/item?id=33525754 - Nov 2022 (4 comments)
Conventional Commits - https://news.ycombinator.com/item?id=30950377 - April 2022 (1 comment)
I Hate Conventional Commits - https://news.ycombinator.com/item?id=29924976 - Jan 2022 (1 comment)
Conventional Commits - https://news.ycombinator.com/item?id=24208815 - Aug 2020 (23 comments)
Conventional Commits: A specification for structured commit messages - https://news.ycombinator.com/item?id=21125669 - Oct 2019 (95 comments)
I can not say anything nice about conventional commits. The format takes up space in the most-read part of the message. The categories or types have little information. They can be replaced with an honest English verb embedded in the subject like a sentence. It also reads way better with just a sentence instead of three kinds of punctuation (:, (), !). Okay, I can tolerate an "area" in the subject. And that predates this conventio.
At my dayjob we make a webapp for non technical people. I can write a changelog for that just fine (in norwegian). The commit messages are irrelevant to the users. And demanding that all commits should be good enough for an end-user changelog? That's not happening for us anytime soon.
Use footers/trailers instead.
> 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.
> 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
You can do the same when you write commit messages. "Wrap user and account update in a transaction" - "Delete temp files after use".
The article is 100% on the mark.
If I only worked with seasoned devs, I wouldn’t use it, but that’s just the reality of my work. It also has a bonus of forcing AI agents to write in the same form as well instead of their random personal flavor. Precommit hooks stop everything before it gets in front of my eyes for review.
And does it actually accomplish that goal? I've been on several projects where someone pushed CC on the team with this reasoning. Every time my experience has been that you get the same crappy messages with a tag that may or may not be accurate.
BTW, AI absolutely knows how to bypass pre-commit hooks and will do so when they come up with some reasoning why their situation is an exception to the rule. I've watched them do it. The only way I've found to strictly enforce things on an agent (tests, linting, whatever) is to use a claude pre-command hook that will block git commit if the checks don't pass.
https://tbaggery.com/2008/04/19/a-note-about-git-commit-mess...
If one needs to put metadata in commits, usually better to just put it in a Git trailer.
https://git-scm.com/docs/git-interpret-trailers
`Co-authored-by: Alice` is a common one, but you can have anything in there.
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
Keep a change log.
Could/should the changelog be considered a first-class deliverable with care and attention provided? I think so, but I'm not in a position to exert direct control over that across dozens of repos and team members.
In my experience, LLMs are great at reviewing changelogs for potential gaps from a user POV (and even creating draft changelogs wholesale, if you're backfilling) based on git history.
Conventional commits are most valuable to me as historical context rather than as a release-management tool.
The larger the project becomes, the more useful that context gets.
And the issue isn't whether you can remember what you changed yesterday; this is largely about making sure other developers can quickly identify relevant commits. If you're a solo non-OSS developer, this is entirely relevant to you.
For GH issues you can always navigate back to the PR discussion (which should have linked issues and other pointers in it) from the commit.
Of course when we switched to GH issues, we largely abandoned JIRA and years later the instance got turned off and deleted. Now all those JIRA tags are entirely useless.
IMO that actually argues for tight coupling between your issue tracker and your git repo. And what you really want is portability (which I don't see how you get other than with tight coupling). Ideally there would be open standardized formats, but as it is, github is the 800# gorilla that defines the format and as long as gitlab and other clones can slurp in github project metadata (or at least PRs) then that effectively gets you closer.
But any way... Fixed, immutable pointers to an Atlassian product that you might not be using in 5 years is not a good policy. I'd sooner accept the policy that the git commits needed to stand entirely on their own and all the information about the "why" of the change needed to be baked into the git commit or the comments in the source (I think that fails, though, since everyone is overly terse in git commits and summarizes issues and loses information--and the back-and-forth dialog in a PR discussion is useful because it contains more than just one person's voice summarizing the reason for the change).
fix thing in foo
Issue: ABC-123
Most tools cross-link them as long as #<issue-id> is mentioned anywhere in the message. It's also useful the other way around, open an issue and see all associated commits.
Personally (without conventional commits) I tend to put them at the end in parentheses if the commit has something to do with that issue. But if there is a stronger relationship like that it fixes the issue, I put a `Fixes` trailer in the message as well.
conventional commits are pleasing, but questionable actual utility. the code speaks for itself. the actually useful information is a well chosen title and the context for the change.
It's fine for it to be in the description.
Why on Earth are people not writing commit messages for their reverts? They should have semantic commit messages just the same as any other commit.
Unless the point is that they're not following per-commit CD, and if you commit then revert that commit before a release was made. That sounds like a process failure. Which of course, process isn't infallible, and neither is the automated version management. If you screw up, use an escape hatch — just like reverting a commit that had previously gone through code review and been merged.
Re: change log generation. The article says change logs shouldn't have commit messages. I agree. Many tools (e.g. Changesets https://github.com/changesets/changesets) use the semantic commit type to sort change log entries, but require you to write those user facing change log entries separately.
Lately I use CalVer instead of SemVer, so it hasn't been an issue. I like the idea of smart auto-bump for versions.
When I encounter a bug in a dependency of mine. Before I worry about submitting a PR, the very first thing I do is grab my version number and check the commit logs for fixes since my version number.
If I'm trying to decide whether I should bother upgrading, I scan the log for new features.
It's the title, not the details. The commit message body should contain MUCH more detail than the title.
If you don't like it because it looks ugly. Sure, that's subjective. And actually, I agree. Because it's standardized though, Git interfaces could even be configured to trim this off and provide different visual styles for the different kinds of commits. The types could be used as search filters too etc.
Now, I get people don't like the look of them. Neither did I when I first saw them. Then I started using them and found them useful.
It's fine, people have different preferences, it's just a convention and it's not going to work for every project. The article itself just doesn't seem to hold any water.
If you have somebody willing to write custom release messages, that's definitely better; but conventional commits is better than nothing for it.
If I'm at the point of contributing a PR to a dependency, I've already identified the root cause in detail. There's no way a change log should be going into that level of detail, or else you're just duplicating the Git log for no reason.
Will the change log make mention of fixing the bug? Perhaps. But I'm going to want to read the technical details of the fix to make sure they've specifically addressed my issue, and not just a similar problem. What is the performance impact of the fix? Are there security implications they've explained in the commit message.
I'm a software engineer, not an end user, I want the technical details of my dependencies.
If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts.
If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed.
And if you don’t have these kinds of dependents, then the versioning scheme isn’t important anyway.
I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch.