Stop Using Conventional Commits - Sumner EvansStop Using Conventional Commits
Posted<br>on 2 June 2026<br>in<br>Software Engineering<br>• 1873 words<br>• 9 minute read<br>Tags:<br>Git, Commits, Scoped Commits, Conventional Commits<br>You’ve almost certainly encountered<br>Conventional Commits before.<br>It may have reared its ugly head in the changelog of an open source project<br>you’ve used. It may have been the enforced commit format for an open source<br>project you contributed to. A lot of people swear by it. I swear at it.<br>Even though it is used by<br>large<br>number<br>of<br>popular<br>open<br>source<br>projects,<br>Conventional Commits is an actively bad standard which<br>encourages focus on the wrong things and<br>fails to deliver on its promises .<br>Focus Failure
Conventional Commits promises to add semantic meaning to commit messages to aid<br>developers and end-users in understanding the changes made in a commit. However,<br>Conventional Commits fails to do this in spectacular fashion. To demonstrate<br>this, let’s look at the anatomy of a conventional commit. According to the<br>Conventional Commit website<br>commit messages should be formatted as follows:<br>[optional scope]:
[optional body]
[optional footer(s)]
The commit’s subject line has a (something like fix, feat, chore,<br>docs, or refactor1) describing the type of change. Following that, there<br>is an optional scope, and then a description.<br>This format has a major failing: type is prioritised over scope . This is<br>exactly backwards.<br>Scope > Type<br>Type"><br>The scope of a change (the subject of the change) is the most important part<br>of a commit. To demonstrate this, let’s consider why each one of the following<br>stakeholders care about the scope of the change more than the type of the<br>change:<br>Contributors: when you are a contributor to a project, you often need to<br>read the commit log to identify changes in the codebase relevant to a certain<br>area of the code. There are many reasons for this including:<br>Wanting to catch up on what has happened since the last time you<br>contributed.<br>Trying to understand where the project’s overall inertia is.<br>Looking for commits that might conflict with your in-progress work when<br>pulling or rebasing.<br>As you read the commit log, you’re looking at what areas were touched. You<br>really do not care about the type of change happening, you care about the<br>scope of the change.
Debuggers: when investigating a bug, you often want to look through the<br>commit log to see what changes might have touched areas related to the<br>component where the bug manifested. Once again, the scope is the most<br>important piece of information. The type of change is entirely useless because<br>bugs can be introduced in any change regardless of type. (I’m sure we’ve all<br>experienced writing a bugfix that caused another bug.)
Incident responders: when production is down, scanning the commit log for<br>changes that were made around the time of the outage is an effective way to<br>identify what areas may be causing the problem. Scope is once again the most<br>important piece of information you can have at this point. For example, if you<br>see a commit related to the auth scope at the tip of the spike of inbound<br>API errors, it’s a likely culprit for the problem. And once again, type is<br>irrelevant because bugs could have been added by any change.
So what does Conventional Commits do? It deprioritises scope so much that it’s<br>optional! Why the hell is scope optional? Having a commit without a scope is<br>like having a sentence without a subject! Then, to add insult to injury,<br>Conventional Commits elevates type to the front of the commit message.<br>Conventional Commits gets the priority of scope and type entirely wrong.<br>Type is Redundant and Restrictive
You might be thinking “so it may be backwards, but commit type is at least still<br>important, right?” and to that I say “no”. A commit’s description should almost<br>always tell you the type of the change! Consider<br>this commit message<br>as an example:<br>fix(compiler): prevent namespaced SVG elements from being stripped
Even if you only had the description, it’s obvious that it was a bugfix! Space<br>on the subject line of a commit is already at a premium, wasting characters on<br>the type is not helpful! But it’s often even worse than useless; it’s often<br>restrictive. Take<br>this commit message<br>as an example:<br>refactor(core): Update webmcp support to use document.modelContext
This commit updated the webmcp functionality in the core component to<br>support both document.modelContext and navigator.modelContext, so was that a<br>bugfix, refactor, or new feature? I would argue it’s all of them! But again, the<br>only thing that really matters is that it was a change to the core/webmcp<br>component.<br>Conventional Commits fundamentally focuses on the wrong thing (the commit<br>type) and devalues the scope (which is what people actually care about).<br>Broken Promises
So we have determined that the format of Conventional Commits sucks,...