Conventional Commits encourages focus on the wrong things

Original Article ↗ Hacker News Discussion ↗

Conventional Commits, a spec for structuring git commit messages (e.g., `feat:`, `fix:`), is under fire for emphasizing machine-friendly tags and automated semver bumps over human-readable context about what changed and why. Critics argue that types like `feat`/`fix` add little value, clutter the most important part of the message, and produce poor autogenerated changelogs, advocating instead for clear prose, scopes, and tools like git trailers or separate changelog files. Supporters counter that even imperfect structure is better than none for large teams, enabling CI/CD automation, consistent release versioning, and quick filtering of changes, especially when most developers otherwise write weak commit messages.

Perceived Benefits of Conventional Commits

  • Many see CC as primarily useful for automation: semantic version bumps, continuous delivery, and basic changelog generation.
  • Type prefixes (feat, fix, chore, docs, etc.) help some reviewers and consumers quickly filter history (e.g., scan for bug fixes or new features).
  • Some like the explicit ! for breaking changes and tools that visually highlight those.
  • In teams with weak commit hygiene, CC is viewed as a lightweight enforcement mechanism that at least forces a structured one-liner.
  • Some developers appreciate at-a-glance signals (sometimes via emojis) about change “blast radius” or who cares about a change.

Core Criticisms

  • Many argue the type prefix is low‑value or redundant; good English verbs and concise titles already convey “fix” vs “feat”.
  • Scope (component/module) is seen as more useful than type, and several large projects use scope-style conventions without CC.
  • Auto-generated changelogs from commits are widely criticized as too granular and aimed at the wrong audience; curated changelogs or release notes are preferred.
  • Semantic versioning inference is seen as brittle, especially with reverts, subtle breaking changes, and monorepos where one commit can mean different things for different packages.
  • Some find CC ugly, wordy, and a distraction in the most important limited real estate: the subject line.

Alternatives and Variations

  • Common alternatives: “scope: description” (Linux/Go-style), scoped commits, git trailers/footers, git-notes, or separate changelog systems (e.g., Keep a Changelog, Changesets).
  • Several suggest moving machine-readable metadata (type, issue IDs, tags) to trailers or separate files, preserving the subject for humans.
  • Issue/ticket IDs are contentious: some want them in the title for quick linking and context; others prefer them in the body or trailers.

Broader Themes

  • Strong emphasis from many on commits explaining “why” rather than just “what” or “how”.
  • Recognition that most teams don’t write good commit messages; some view any enforced convention as better than nothing, others say CC doesn’t solve the underlying quality problem.
  • Multiple commenters see this as bikeshedding: useful to have some convention, but arguing type vs scope order is seen by some as low-value.