Why should my commit description be in the imperative mood?

The imperative mood ('add feature' rather than 'added feature' or 'adds feature') aligns with how Git itself generates default merge and revert commit messages ('Merge pull request #12', 'Revert commit abc').

How do I signal a breaking change?

Check the 'Breaking Change (!)' box. This adds an exclamation mark after the type/scope (e.g. feat(api)!: ...) and appends a BREAKING CHANGE: explanation in the footer, notifying automated tools to bump the major version.

Developer Utilities

Conventional Commits Builder

The problem: Inconsistent git commit messages make automated changelog generation and semantic versioning impossible across engineering teams.

ASG Privacy VerifiedVerified

100% In-Browser Execution. Zero server uploads. Your data never leaves this tab — disconnect your internet and the tool keeps working.

ASG Privacy VerifiedVerified

100% In-Browser Execution. Zero server uploads. Your data never leaves this tab — disconnect your internet and the tool keeps working.

Commit ParametersInclude Gitmoji

Type

Scope (optional)

Short Description (imperative mood)

Detailed Body (optional)

Breaking Change (!)

Closes Issues (optional)

Formatted Commit Message

✨ feat(auth): add google oauth login support

Implements Google OAuth flow with PKCE authentication and JWT session token generation.

Closes #42, #88

1-Click Git CLI Command

git commit -m "✨ feat(auth): add google oauth login support" -m "Implements Google OAuth flow with PKCE authentication and JWT session token generation." -m "Closes #42, #88"

Conventional Commits Builder: the complete guide

A Conventional Commits generator provides an interactive, structured form to build standardized git commit messages conforming to the Conventional Commits 1.0.0 specification. Standardized commit messages allow software engineering teams to automate semantic versioning (SemVer), generate clean changelogs with tools like Release Please or Semantic Release, and maintain a readable repository history. This tool ensures your commit type, scope, imperative summary, body, breaking change markers, and issue tracker references are formatted without syntax errors.

The Conventional Commits Specification

The Conventional Commits specification defines a lightweight convention on top of commit messages. It provides an explicit semantic structure: <type>[optional scope]: <description>, followed by an optional body and optional footer. Types like 'feat' signal a MINOR release under SemVer, 'fix' signals a PATCH release, and appending a '!' after the type/scope signals a MAJOR breaking change.

Changelog and Release Automation

When whole engineering teams adopt structured commits, automated CI/CD pipelines can parse the git history to automatically determine whether to release v1.2.0 or v2.0.0, create GitHub releases, and update CHANGELOG.md files without manual developer intervention.

Step by step: how to use Commit Builder

1
Select the commit type (feat, fix, docs, refactor, perf, chore, etc.).
2
Optionally provide an architectural scope (e.g. auth, checkout, ui).
3
Enter a concise summary written in the imperative mood ('add user endpoint', not 'added').
4
Optionally add a detailed multi-line body providing motivation and background context.
5
Toggle the Breaking Change checkbox if backwards compatibility is broken.
6
Enter any associated issue tracker ticket numbers (e.g. #102, #205).
7
Copy the formatted message or the 1-click git CLI command.

Security & privacy

This tool operates completely client-side in your browser. No project names, internal ticket numbers, or commit messages are uploaded to any server.