Git Commit Message Formatter

Well-formatted commit messages make project history readable and searchable. Conventional Commits provides a consistent structure: type(scope): description. This enables automated changelog generation, semantic versioning, and easier code review. Tools like semantic-release and commitlint rely on this format.

A good subject line is imperative, under 72 characters, and summarizes the change. The body provides context; the footer links issues and documents breaking changes. This formatter helps you compose messages that follow best practices.

feat: a new feature. fix: a bug fix. docs: documentation only. style: formatting, missing semicolons, etc. refactor: code change that neither fixes a bug nor adds a feature. perf: performance improvement. test: adding or correcting tests. build: build system or external dependencies. ci: CI configuration. chore: other changes. revert: reverts a previous commit.

Each type signals intent to automated tools and humans. Use the most specific type that applies. For breaking changes, add ! after the type/scope or use BREAKING CHANGE: in the footer.

Use the imperative mood: 'Add feature' not 'Added feature'. Keep the subject line under 72 characters. Separate subject from body with a blank line. Wrap the body at 72 characters. Use the footer for breaking changes and issue references. Reference issues with Closes, Fixes, or Resolves.

This tool provides a live preview so you can see exactly how your commit will look. The character count warns when the subject exceeds 72 characters. One-click copy makes it easy to paste into your terminal.