💬 Conventional Commit Generator
Write perfect semantic commit messages (Angular/Conventional Commits spec)
How to Use the Git Commit Generator
The Conventional Commits specification creates a consistent, machine-readable commit history that enables automatic CHANGELOG generation and semantic versioning. Select your commit type (feat for new features, fix for bug fixes, docs for documentation), optionally add a scope (the part of the codebase affected), then write a short description in imperative mood ("add login page" not "added login page"). For complex changes, use the Body to explain the "why". Tick Breaking Change if the change is not backwards-compatible (this bumps the major semver version).
feat(auth): add OAuth2 Google login
Allows users to sign in with their Google account.
Implements PKCE flow for enhanced security.
Closes #234Common tools that read conventional commits: semantic-release (auto version bumping), standard-version, conventional-changelog (auto CHANGELOG). GitHub and GitLab display the type prefix prominently in their UI, making your git log much easier to scan.
What is the Conventional Commits specification?
Conventional Commits is a commit message format that enables automated tooling: <type>[optional scope]: <description>. Types: feat (new feature), fix (bug fix), docs (documentation), style (formatting), refactor (code restructuring without feature change), test (adding tests), chore (build process, dependencies), perf (performance improvements), ci (CI configuration). A breaking change is indicated by ! after the type: feat!: change API response format, or with a BREAKING CHANGE: footer. This format enables automatic changelog generation, semantic versioning, and release automation with tools like semantic-release.
How should I write a good commit message description?
The description (the part after the colon) should: use imperative mood ("add user authentication" not "added" or "adds"), be under 72 characters for the first line, not end with a period, describe what the change does — not how or why. Good: feat(auth): add JWT refresh token rotation. Bad: fix: fixed the thing that was broken. The body (separated by blank line) explains why the change was made and what alternatives were considered. The footer cites issue numbers: Closes #234, Fixes #678. Refs #90.
What is the difference between fix, refactor, and chore?
fix: corrects a bug — something that was broken is now working correctly. This type triggers a PATCH version bump in semantic versioning. refactor: changes code structure or implementation without changing external behavior or fixing a bug — no user-visible difference, just cleaner/faster/clearer code. chore: maintenance tasks that do not affect the application code or tests: updating dependencies, configuring build tools, adding .gitignore rules, updating package.json scripts. Neither refactor nor chore typically triggers a version bump in automated release tools.
How do commit message conventions enable automated versioning?
Tools like semantic-release and standard-version read commit history and determine the next semantic version automatically. fix: commits increment the PATCH version (1.2.3 → 1.2.4). feat: commits increment MINOR (1.2.3 → 1.3.0). feat!: or any commit with BREAKING CHANGE: increments MAJOR (1.2.3 → 2.0.0). The tool also generates a CHANGELOG.md by grouping commits by type. This eliminates manual version number decisions and changelog writing — the commit history becomes the source of truth for releases.
How do I enforce commit message format in a team?
Use commitlint (npm install --save-dev @commitlint/cli @commitlint/config-conventional) with a Husky git hook that runs commitlint on every commit. Add a commit-msg hook: npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'. Non-conforming commits are rejected before they enter the repository. For interactive guided commit creation, use Commitizen (git cz instead of git commit) — it prompts for type, scope, description, and breaking changes. Both tools use the same @commitlint/config-conventional configuration.
Should I include the scope in every commit?
Scope is optional but useful in monorepos or large codebases: feat(payment): add Stripe webhook handling. Scopes typically correspond to packages, modules, or system areas: feat(auth), fix(api), docs(readme), chore(deps). In small repositories, scope adds noise without much value. In monorepos with multiple packages, scope is essential to understand which package a commit affects. Consistent scope names also enable changelog filtering: show me only commits affecting the auth module this release.
What other developer workflow tools are on this site?
The Gitignore Generator creates .gitignore files with patterns for your tech stack. The Diff Checker compares code changes before committing. The Semver Calculator helps understand version number implications of your change type. The Package JSON Generator creates package.json files for new projects. The Markdown Preview lets you preview README and documentation changes. All are in the Dev Tools section.
📊 Key Data Points
Conventional Commits
Specification used by Angular, Vue, Next.js, and thousands of projects
72 chars
Git subject line limit for readable git log --oneline output
semantic-release
Reads Conventional Commits to auto-bump semver and generate changelogs
Git Commit Message Generator — Conventional Commits -- Complete USA Guide 2026
A good commit message tells reviewers what changed and why — in a format that makes git log useful. Conventional Commits (feat(scope): description) enables automated changelogs and semantic versioning but the format is easy to get wrong.
This generator builds Conventional Commit messages with correct format and optional emoji. Runs in your browser.
**Long-tail searches answered here:** conventional commits message generator online free, semantic commit message builder with gitmoji, how to write git commit message correctly browser tool.
For repository setup, pair with Gitignore Generator and Package JSON Generator.
🔬 How This Calculator Works
Builds messages in <type>(<scope>): <description> format. Types: feat, fix, docs, style, refactor, test, chore, ci, build, perf. Validates: description starts lowercase, no trailing period, subject line under 72 characters (the Git convention for readable git log output). Breaking changes use feat!: notation or BREAKING CHANGE: footer. Optional emoji prefix for gitmoji convention.
✅ What You Can Calculate
Conventional Commits format
Produces correctly formatted type(scope): description messages that enable automated changelog generation with semantic-release and standard-version.
72-character subject limit
Warns when the subject exceeds 72 characters — the Git convention for readable git log output.
Breaking change notation
Supports feat!: notation and BREAKING CHANGE footer for major version bumps in automated release workflows.
Gitmoji support
Optionally prefixes the type with emoji — a popular convention for visually scannable commit history.
🎯 Real Scenarios & Use Cases
Setting up semantic-release
semantic-release reads Conventional Commit types to bump versions and generate changelogs. Use this generator to write commits in the correct format from day one.
Team commit style consistency
Share this tool with your team as a reference for the commit format your project uses. Consistent commit history makes git log meaningful.
PR commit message quality
Before pushing a PR, format commit messages here. Reviewers scanning history should understand what changed without reading the diff.
Open source contribution
Many open source projects require Conventional Commits for automated releases. Generate correctly formatted messages to meet contribution guidelines.
💡 Pro Tips for Accurate Results
Lowercase description, no trailing period. Conventional Commits spec requires: feat: add user authentication not Feat: Add user authentication with trailing period.
Scope clarifies context. fix(auth): handle expired tokens vs fix: handle expired tokens — scope makes git log much more useful in large codebases and monorepos.
One logical change per commit. A commit titled feat: add login, fix sidebar, update deps is three commits. Atomic commits make bisect, revert, and cherry-pick practical.
BREAKING CHANGE in footer for majors. Add BREAKING CHANGE: description after a blank line for changes that warrant a major version bump in semantic-release.
🔗 Use These Together
🏁 Bottom Line
Commit messages are team documentation. A year of Conventional Commits gives you an automatically generated changelog and readable code narrative. For a complete repo setup: generate commits here, configure with Gitignore Generator, manage dependencies with Package JSON Generator.