Everyone Uses Conventional Commits. Maybe That's the Problem.

Open almost any Git log from the last few years and you’ll see them: feat:, fix:, chore:. Conventional Commits — the agreement to write commit messages in a fixed format — has quietly become the closest thing the industry has to a standard. So it’s worth noticing that on Hacker News and Reddit, a counter-argument keeps resurfacing: maybe we should stop. Why are developers questioning a rule almost everyone already follows?

One honest caveat first. This isn’t some fresh controversy that blew up last month. It’s an old argument that flares up every year or two and never quite dies. Which is exactly why it’s worth revisiting — developers keep chewing on it because the underlying tension never got resolved.

What Conventional Commits Actually Is

The rule is simple. You prefix the first line of a commit with a defined type. New feature? feat. Bug fix? fix. Routine maintenance? chore. A typical message looks like this:

feat(auth): add password reset endpoint

Type, an optional scope in parentheses, then a one-line summary. The payoff for following this template is real, and the biggest draw is automation. Tooling can count how many feat and fix commits have piled up, bump the version number accordingly, and generate a CHANGELOG without anyone touching it. Tools like semantic-release are built entirely on top of this convention.

There’s a consistency win, too. Whoever writes the commit, you can read the first word and immediately know its character. That clarity is why countless open-source projects adopted it.

“The Whole Point Is the Why”

This is where the pushback begins. The core complaint is that Conventional Commits trains you to obsess over what a commit did.

Think about it. A message like fix: resolve login bug carries almost no information. The diff already tells you a bug got fixed. What the colleague reading this commit six months from now actually wants to know is something else entirely: why it was fixed this way, what alternative approaches were tried and abandoned, and what side effects the change might introduce.

The critics argue that the real substance of a good commit message lives in the body. And while you’re busy deciding whether the subject line deserves a feat or a fix label, the context and decision-making that deserve a full paragraph get shoved aside. The format gets filled in, the body stays empty, and people walk away feeling like they did the job.

The Categories Are Blurrier Than They Look

The other gripe is the ambiguity of the categories themselves. The moment you actually sit down to commit, you hit it: is this a feat, a fix, or a refactor?

You improved performance, but the behavior shifted slightly in the process — which type is that? You refactored, and the cleanup happened to squash a bug too. Real commits rarely fall cleanly into a single bucket. So every developer makes a different call, and inside the same team the same kind of work ends up with different labels. A rule introduced for consistency ends up manufacturing a new kind of confusion.

There’s a sharper edge here. A mislabeled type breaks automated versioning. Tag a trivial tweak as feat by accident and your version jumps when it shouldn’t. The convenience of automation flips into the liability of automation at exactly that point.

Culture Beats Format

None of this means Conventional Commits is simply bad — that conclusion is too quick, and even the critics concede the point. For a library or a large open-source project that genuinely needs automated releases, the convention earns its keep.

The deciding factor is context. If your environment requires a machine to mechanically parse every message, the format matters. But if your priority is humans reading and understanding the history, a culture of writing a thorough body is worth far more than a prefix rule.

So the real question was never “should we use Conventional Commits or not.” It’s “do our commit messages actually help someone in the future.” The format is only a means to that end — and the worry is that somewhere along the way, the means quietly became the goal.

Following a rule is easy. Leaving good context behind in writing is the hard part. What will your last commit message tell a colleague six months from now? It might be time to check whether, just past that one-word prefix, the story actually worth telling is missing.