HN Debrief

Conventional Commits encourages focus on the wrong things

  • Programming
  • Developer Tools
  • Open Source
  • Infrastructure

The post says Conventional Commits optimize for the wrong reader. Prefixes like `fix:` and `feat:` are meant to help automation, but they consume the most valuable space in a commit subject while telling future maintainers very little that a well-written sentence would not already convey. The author’s alternative is to lead with scope when it helps, or just write a clear imperative subject line and keep release notes as a separate, curated artifact rather than pretending commit logs are user-facing changelogs.

If you use Conventional Commits, treat them as automation glue, not as a proxy for good history. For teams that care about maintainability, put the human explanation in the subject and body, and move machine-readable metadata like issue IDs or release hints into trailers or separate release tooling.

Discussion mood

Mostly skeptical of Conventional Commits as a human communication tool, with repeated frustration that they smuggle release automation concerns into the most visible part of a commit message. The more sympathetic comments defended them as an enforceable baseline for mediocre teams, not as an ideal format.

Key insights

  1. 01

    Git outlives Jira and PR systems

    External issue trackers and review tools are bad places to store the only explanation for a code change because they vanish, get merged badly, or become inaccessible long before the repository dies. That sharpens the distinction between a ticket, which captures product and process context, and a commit message, which should explain the code-level reason this diff exists in a form that survives migrations and works offline.

    Keep enough rationale in the commit itself that a maintainer can make progress without Jira, GitHub, or network access. Link out to tickets if you want, but do not make the repo dependent on them for basic understanding.

      Attribution:
    • Izkata #1
    • andrybak #1
    • lelandfe #1
    • mmcnl #1
  2. 02

    Trailers are the right place for metadata

    Git already has a built-in structured field system for machine-readable data, and several commenters argued teams should use it instead of stuffing issue IDs and release hints into the subject line. That preserves the headline for humans while still giving CI, custom log views, and automation reliable fields like `Issue:` or `Fixes:` to parse.

    If you need structured data in commits, standardize trailers before inventing more subject-line syntax. You get cleaner logs for humans and less brittle parsing for tooling.

      Attribution:
    • jibcage #1
    • epmatsw #1
    • c-hendricks #1
    • tomjakubowski #1
  3. 03

    Monorepos break commit-based release notes

    Commit-level labeling falls apart once one repository produces multiple artifacts or packages. A single change can be a breaking change for one package, a refactor for another, and irrelevant to a third, yet Conventional Commit tooling usually sees one global label and sprays it everywhere. That is why commenters preferred Changesets and curated changelogs, which let maintainers describe releases at the package or product level instead of pretending one commit maps cleanly to one release note entry.

    If you ship multiple packages from one repo, stop expecting commit prefixes to generate accurate release communication. Use release-specific metadata like Changesets or maintain package-level notes explicitly.

      Attribution:
    • turadg #1
    • pseudalopex #1
    • olivierlacan #1
  4. 04

    CC now doubles as tool control

    Several defenders were not really defending the semantics at all. They were defending the ability to make humans, bots, and AI coding agents emit a uniform shape that can be rejected automatically when it drifts. That shifts the value proposition from better communication to easier governance. It also explains why terms like `chore` survive despite being vague and disliked. They work as buckets for linters and agents even when they read badly to humans.

    Be explicit about why you enforce a format. If the real goal is operational control over contributors and AI agents, say that, and do not confuse it with improving the explanatory quality of history.

      Attribution:
    • Merad #1
    • layer8 #1
    • jsve #1
  5. 05

    SemVer automation needs escape hatches

    Even commenters who liked Conventional Commits for continuous delivery admitted the system gets awkward around reverts, pre-release workflows, and manual releases. The useful pattern was not blind trust in commit types. It was commit types plus override mechanisms such as manual version bumps in tools like release-please, or abandoning fully inferred versions in favor of `git describe` and human tagging.

    If you auto-bump versions from commit metadata, budget for overrides from day one. A release process that cannot represent exceptions will teach people to distrust the version numbers.

      Attribution:
    • drfloyd51 #1
    • beart #1
    • claytonjy #1
    • boltzmann64 #1

Against the grain

  1. 01

    A mediocre standard beats no standard

    For many teams the realistic comparison is not Conventional Commits versus beautifully crafted prose. It is Conventional Commits versus a history full of `small fix`, `updates`, and random style drift. From that angle, the exact ordering of type and scope barely matters. What matters is having something enforceable that creates consistent expectations and reduces review noise.

    If your team routinely produces useless commit subjects, start with any simple enforceable convention before chasing the perfect one. You can refine the schema later once the habit of writing intentional messages exists.

      Attribution:
    • hn_throwaway_99 #1
    • SOLAR_FIELDS #1
    • bfeynman #1
    • NeutralCrane #1
  2. 02

    Type-first is useful for dependency consumers

    A minority argued that commit type is not just release tooling baggage. It helps people scanning dependency history decide quickly whether to look for fixes, features, or breaking changes since their current version. For plugin and library users, a visible breaking-change marker or a quick filter over `fix` commits can be more actionable than scope alone.

    If you publish libraries and your users actually read raw history between releases, preserving visible type markers may be worth the subject-line space. Validate that behavior with your consumers rather than assuming only maintainers matter.

      Attribution:
    • epage #1
    • Benjamin_Dobell #1
    • zenoprax #1
    • shmerl #1
  3. 03

    Ticket IDs are the most useful first glance

    Some commenters cared far less about commit taxonomy than about traceability to the originating request. For them the fastest route to understanding an old change is a clickable ticket key in the title, because the diff already shows what changed while the external issue often captures the feature request, contract requirement, or bug report that motivated it.

    If your organization works through tickets and people routinely navigate history through issue links, keeping a compact issue key visible can be justified. Just make sure the commit still stands on its own when the ticket system fails you.

      Attribution:
    • ralferoo #1
    • mh-cx #1
    • IshKebab #1

In plain english

Changesets ↩
A tool and workflow for storing release notes and version bump information as separate files rather than inferring them from commit messages.
Conventional Commits ↩
A specification for formatting commit messages with prefixes like `feat:` or `fix:` so they can be read by humans and tools.
git describe ↩
A Git command that names a commit relative to the nearest tag, often used to generate build or release identifiers.
Keep a Changelog ↩
A widely used guide that argues for manually curated changelogs written for users rather than raw commit-derived logs.

Reference links

Commit message guidance

Alternatives to Conventional Commits

Release notes and versioning tools

  • Changesets
    Recommended as a better way to manage package-level changelogs and version bumps
  • release-please
    Mentioned as a tool with manual overrides for awkward SemVer cases like reverts
  • Keep a Changelog
    Referenced to support curated changelogs written for users
  • Keep a Changelog v1.1.0
    Pointed to by the article author as aligning with the post's argument

Git metadata features

Related tools and side references

  • word-weasel
    Shared as a natural-language linter for teaching clearer technical writing
  • ReleaseJet discussion
    Included in a list of related previous discussions about release notes without Conventional Commits
  • JSON5
    Mentioned in a side discussion about standards that trade strictness for human usability