Stop Using Conventional Commits

The real takeaway is that different projects have different requirements.

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.

Article is too opinionated IMO. I enforce CC on my projects because I don’t have the energy to police horrendous commit messages. It’s easy to enforce the CC format on the repo merge policy. I do it with the addition of a required issue ID as well.

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.

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 felt that this habit is kind of standard - until i had to learn about "conventional commits".

I never got the hype.

The use of the word "chore" in many users of conventional commits has always riled me. I've always tended to favour the "linux kernel"[0] style of commit subject, which thankfully gets a mention here.

[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

I'd much rather people think deeply about summarizing their work. This helps others understand it but, more importantly, helps the developer understand what they did. If its hard to summarize, maybe it should be tightened up a little for instance. Enforcing a "schema" might help a tiny bit but also can cause people to check out a little as it can feel like just another meaningless process.

I quite dislike this style of writing titles. "Stop something". I seems very popular. It sounds very commanding and "I am definitely right about this". Why not write "In favour of something" or "A case against something" or something like that?

“The audience of a changelog is entirely different than the audience for a commit log!

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.

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 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.

The thing conventional commits are really helpful for is continuous delivery. Every merge to main can be automatically tagged with semver and shipped because the thought that goes into tagging and versioning has already been done by the developers when they wrote the commit message.

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.

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.

Want machine-readable? Use the footers/trailers.

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.

I think any notation is use case specific and should be adapted to beat serve its domain.

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

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.

As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago.

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.

I have never been involved in a project where people make good commits. Having a convention at least forces people to make thoughtful one-liners.

There’s a much less awkward way to keep a change log:

Keep a change log.

Definitely agree that generating change logs from commits leads to confusing change logs for people that expect to see what changed between versions. A big long list of commits is too granular. A curated and summarized list of changes is much more in-line with what most people expect when reading a change log.

I totally agree.

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.

I think some structure in commit messages is helpful, but not to the point where it gets in the way of effectively reflecting what the commit contains, why it was done, and any comments for future reference, e.g. potential regressions.

I have long despised Conventional Commits for pretty much these reasons. Yes, it’s structure, but it’s not useful structure. Of the five things it claims to enable, three are nonsense and the other two are actively bad.

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.)

This entire essay is just about how it should be "<scope> <optional type>" instead of "<type> <optional scope>"?

Couldn't agree more with this. The commit type tells me almost nothing and just wastes my time skipping over it. Scopes are way more useful.

Asides from the well made points here ('scope is more important than type' etc).

> 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

- FreeBSD

  prefix: description

- Git

  area: description

- Go

  package: description

- nixpkgs

  pkg-name: description

And then you have me, using gitmoji

Mine is “ticket id - Imperative phrase”. Then I write a “why” description of the changes if needs be. As for personal project, I quite like the scoped commits style.

terrible suggestion, people are awful at writing commit messages and the type is really helpful when you're reviewing history and want to know things at a glance

I don't care much what it says as in "fix", "chore" etc, but for me the main benefit is breaking changes indicated with "<type>!", something like "feat!: ... ".

This 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 really dont care about commit messages. Just create strict rules for branches that contains issue nr + description, and squash all commits on merging the PR.

The real takeaway is that different projects have different requirements.

Want machine-readable? Use the footers/trailers.

Use footers/trailers instead.

I think any notation is use case specific and should be adapted to beat serve its domain.

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

I have never been involved in a project where people make good commits. Having a convention at least forces people to make thoughtful one-liners.

I totally agree.

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.

And it’s ugly.

This entire essay is just about how it should be "<scope> <optional type>" instead of "<type> <optional scope>"?

And then you have me, using gitmoji

Mine is “ticket id - Imperative phrase”. Then I write a “why” description of the changes if needs be. As for personal project, I quite like the scoped commits style.

terrible suggestion, people are awful at writing commit messages and the type is really helpful when you're reviewing history and want to know things at a glance

I don't care much what it says as in "fix", "chore" etc, but for me the main benefit is breaking changes indicated with "<type>!", something like "feat!: ... ".

This 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 really dont care about commit messages. Just create strict rules for branches that contains issue nr + description, and squash all commits on merging the PR.

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.

I never got the hype.

I personally prefer including issues as git trailers:

    fix thing in foo

    Issue: ABC-123

Git has plenty of builtins for parsing and formatting these trailers, so you can easily create custom git log aliases that let you see them inline and parse them for use with CI.

Personally, if I am skimming a change log that is already limited in characters, I don’t care about ‘XYZ-999999’ in the main commit message. It’s good to tag as a trailer but I’d much rather see what the commit did than the Jira issue it came from.

Interesting, I guess we've been doing it wrong this whole time, as we do `fix(ABC-123): some message here`, which ends up being linked great, renders very nicely into the automated release notes, etc.

It isn't a standard, it is a convention. You can set a standard within your team to include the ticket id in the commit message.

IMO that is only a problem for those who demand that the issue key needs to go first in the subject (which again IMO is bad for readability). I don't see why you can't just stick it somewhere after all the conventional commits junk? Issue keys ought to be something that can be janked out based on a regex like an alphanumeric prefix followed by a number, so things like this "standard" have little need to set aside a space for it.

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.

yeah this is the actual key. an actually useful title and a stable link to the discussion around the change.

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.

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.

[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...

Completely agree, the attitude implied by “chore” is very off-putting to me. As if the rest should all be marked “fun” or “indifferent”. That kind of emotional judgement doesn’t belong in a commit message.

I found an alternative word: "upkeep"

Same idea without the pejorative aspect.

“The audience of a changelog is entirely different than the audience for a commit log!

A changelog is user-facing”

The best thing that I'd used for auto-updated software with weekly updates was to prefix user-facing visible commits with "uv:" Then each week we search for them and either use the text as-is or massage it slightly. We even got it into the product itself in the Help/Release-notes menu.

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.

Why not be direct and advocate clearly for the position that you prefer? You don’t have agree with their position, but asking them to water down their words is weak sauce.

Our interest in a statement is piqued more when it challenges our worldview. It's impolite to a lot of people, but the attention economy rewards it.

Not as bad as "considered harmful" imo but still mildly toxic. I think the point is taking one rando's personal preferences (I'd prefer we swap the order of A and B) and trying to make it sound like something more than it is.

I came to say something similar.

I don't like conventional commits much neither, but let the people use whatever they want!

Because you don't get attention if you don't write deliberately inflammatory content.

https://knowyourmeme.com/memes/stop-doing-math

There is a meme that inspires some of this genre of title, fwiw

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.

The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience

Use some convention for git trailers then. Having “fix” or “feat” in the commit title does not provide any useful information to someone scanning the log.

No no. You see we need to get rid of conventional commits so AI can make commits easier.

I do this on my OSS projects to automate semver bumps and it's amazing! At work, I also enforce "tags" (not git tags, just strings in the PR title) based on who cares about the change and then generate changelogs for the respective teams based on those "tags".

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.

Whole idea of CC is to write commits in away that is easy to generate change logs. If you utilize CC correctly or not, at best you get: commit log that harder to read, changelog that is hard to read and still requires you to write highlights (guess minor and path releases are 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).

yep. I'm on the fence about types generally, but "fix:" saves/standardizes a bunch of phrases like "fix an issue where", "prevent" or having to invert the message by describing the solution instead.

I've seen Claude Code aggressively use Conventional Commits, even when the project its working on doesn't use them.

As a solo developer, I rarely struggle to remember what changed yesterday. I often struggle to remember why I made a decision six months ago.

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.

This sounds like what regular commit messages do. How are conventional commits specifically helpful?

That information should still be in the commit messages. "No functional change intended." appears widely in FreeBSD commit logs when code is being refactored (or, rarely, restyled).

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.

There’s a much less awkward way to keep a change log:

Keep a change log.

This is not without struggles. Many times the changelog updates are missed. You can try to catch this in code review, but that could also be missed. So you can try to automatically verify the changelog was updated, but you can't force that as a pass/fail check since not all changes require a user facing change. Or your project maintainers simply copy the commit message and paste it into the changelog, and at that point, why not just automate it with something like conventional commits?

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.

I 100% agree. I found https://keepachangelog.com/en/1.1.0/ as I was writing the article which advocates for exactly this!