ModernCalcs

Conventional Commit Generator

Build a properly formatted Conventional Commits message with a live preview — no more guessing the syntax.

feat: add password reset flow

Conventional Commit Generator: Build the Message, Don't Memorize the Syntax

Conventional Commits has a precise but easy-to-forget syntax: type, optional scope, an optional '!' for breaking changes, a colon, then the description — followed by an optional body and footer. This generator turns that syntax into a simple form with a live preview, so you get correctly formatted messages every time without memorizing the spec.

Formula
type(scope)!: description

Optional body after a blank line, optional BREAKING CHANGE: and issue-reference footers after another blank line.

Why Structure Your Commits at All

Tools like semantic-release parse Conventional Commits automatically to decide whether a release is a major, minor, or patch bump, and changelog generators use the type to group entries into 'Features', 'Bug Fixes', and so on. A consistent format turns your commit history into structured data instead of free-form prose.

Marking Breaking Changes Correctly

There are two ways to signal a breaking change: adding a '!' right after the type/scope (e.g. feat(api)!: remove legacy endpoint), and/or adding a 'BREAKING CHANGE:' footer with a description of what changed and how to migrate. This generator does both automatically when you check the box.

Body vs. Footer

The body is free-form prose explaining the reasoning behind a change. The footer is for structured metadata — issue references like 'Closes #123', co-author trailers, or the BREAKING CHANGE note — each typically on its own line, separated from the body by a blank line.

Practical Examples

A Standard Feature Commit

The most common case.

  • 1.Type: feat, Scope: auth
  • 2.Description: add password reset flow
  • 3.Result: feat(auth): add password reset flow

A Breaking API Change

Flagging a major version bump.

  • 1.Type: feat, Scope: api, Breaking: checked
  • 2.Description: remove deprecated v1 endpoints
  • 3.Result: feat(api)!: remove deprecated v1 endpoints
  • 4.Footer: BREAKING CHANGE: v1 endpoints removed, migrate to v2

Fields in This Generator

  • Type: feat, fix, docs, refactor, and more
  • Scope: optional area of the codebase affected
  • Description: short imperative summary
  • Body: optional context and reasoning
  • Breaking Change: adds '!' and a BREAKING CHANGE footer
  • Footer: issue references like 'Closes #123'

Tools That Read Conventional Commits

  • semantic-release: automated versioning and changelogs
  • commitlint: CI-time enforcement of the format
  • GitHub / GitLab release notes: auto-generated from commit types
  • Renovate/Dependabot: PR titles often follow the same convention

Frequently Asked Questions

What is a 'breaking change' in Conventional Commits?

A change that isn't backward-compatible — for example, removing a public API or changing a function's signature. Marking it adds a '!' after the type/scope and a BREAKING CHANGE footer, which semantic-release-style tools use to trigger a major version bump.

Do I need to fill in a scope?

No, scope is optional. 'fix: correct off-by-one error' is a perfectly valid Conventional Commit without a scope in parentheses.

What goes in the body vs. the description?

The description (subject line) is a short, imperative summary — 'add password reset flow'. The body explains the reasoning or context in more detail — why the change was needed, not just what changed, since the diff already shows what changed.

What's the footer for?

Common uses are issue references (Closes #123, Refs #45) and the BREAKING CHANGE note. Multiple footers are separated by blank lines.

Why does the description field say to use imperative mood?

Convention: a commit message should read naturally after 'If applied, this commit will ___' — so 'add' works, but 'added' or 'adds' don't fit that pattern as cleanly.

Does this tool create the actual git commit for me?

No. It only builds the message text. Copy the output and use it with git commit -m "..." or paste it into your editor when git opens the commit message file.

Can I use this alongside a commit linter?

Yes — generate the message here, then paste it into a Conventional Commits linter (like our Git Commit Linter tool) to double-check formatting before committing.