What is a Conventional Commit message?

It is a specification that puts the change type up front (feat, fix, chore, docs, refactor, perf, test, build, ci, style, or revert) followed by an optional scope in parentheses and a short description, so tools like commitlint and semantic-release can read history automatically. The full format is type(scope): description, with a body and footers underneath when more context is needed.

What's the difference between the ! marker and a BREAKING CHANGE footer?

Both mark the commit as a breaking change for semver purposes, but ! is a one-character annotation placed after the type/scope (feat!:), while the footer is a multi-line block at the bottom that explains what breaks and how to migrate. You can use either or both — semver tools treat them as equivalent signals.

What types should I pick for a docs-only or chore change?

Use docs for documentation changes only, and chore for maintenance work that does not affect production code or tests (dependency bumps, config edits, tooling changes). If you are refactoring code without fixing a bug or adding a feature, refactor is the right type.

Is my commit message sent anywhere?

No. The builder runs entirely in your browser and only outputs a string you can copy into git commit -m. Nothing about your message, scope, or body is uploaded.

Git Commit Message Builder

Build conventional commit messages following commitlint standards

Commit Details

Commit Type

Scope (optional)

Breaking Change

Include ! after type/scope

Description

Use imperative mood (lowercase). Don't end with period.

Body (optional)

Footers (optional)

Templates

Examples

feat(api): add rate limiting middleware

fix(auth): resolve token expiration issue

docs(readme): update installation instructions

refactor(components): extract common logic to useButton hook

feat!: change prop types for Button component

fix(db): prevent duplicate user entries on concurrent creation

perf(images): lazy load images below the fold

test(auth): add unit tests for OAuth flow

style: format code with prettier

chore(deps): upgrade to Next.js 14

Generated Message
Invalid

feat:

How to Keep a Changelog Your Users Will Actually Read

The Keep a Changelog conventions — the six standard categories, how they map to semantic versioning, and what to leave out.

.env Secret Safety Linter

Validate .env syntax and spot likely leaked credentials or placeholder secrets.

.htaccess Generator

Build an Apache .htaccess — HTTPS redirects, rewrites, error pages, security headers, and basic auth

2D Fluid Dynamics & Particle Physics Sandbox

A physics playground with two engines sharing one canvas. The fluid mode runs a real Eulerian Navier-Stokes solver — semi-Lagrangian advection, explicit diffusion, Jacobi pressure projection and vorticity confinement — that you paint with dye and velocity using mouse or touch. The particle mode is a damped Verlet N-body engine with gravity wells, Coulomb attractors and repulsors, spring links, wall restitution and elastic circle collisions. Particle counts adapt to the device (100k target on WebGL2 desktop, 2k-5k on CPU fallback), and every configuration exports as runnable code: a Matter.js world, a PixiJS ticker setup, or a standalone vanilla Canvas engine.

AI Function Calling Schema Generator

Generate function calling JSON schemas from TypeScript interfaces

Algorithm Arena & Data Structure Visualizer

Interactive arena for algorithms and data structures: eight sorting algorithms racing on one seeded input, six pathfinding algorithms walking generated mazes, and BST, AVL, Red-Black, B-tree, heap and trie operations replayed step by step with rotations highlighted. Every run shows the Big-O table and the phase-highlighted reference implementation in four languages, and compared values can be played as pitch (sonification) through the shared audio engine. Everything runs client-side; inputs never leave the browser.

Ansible Playbook Generator

Build an Ansible playbook — hosts, vars, and tasks with modules — as YAML