Create well-formatted git commit messages following Conventional Commits, Angular, or Gitmoji conventions. Live preview, real-time validation, and one-click copy of the full git command.
Commit Details
Breaking Change !
Footer
Live Preview
Start typing to see your commit message...
git commit -m "..."
History (last 5)
No saved messages yet.
Format Guide & Cheat Sheet
The Conventional Commits format: <type>(<scope>): <description>
feat
A new feature (correlates with MINOR in SemVer)
fix
A bug fix (correlates with PATCH in SemVer)
docs
Documentation only changes
style
Formatting, semicolons, whitespace (no code logic change)
refactor
Code change that neither fixes a bug nor adds a feature
perf
A code change that improves performance
test
Adding missing tests or correcting existing tests
build
Changes to the build system or external dependencies
ci
Changes to CI configuration files and scripts
chore
Other changes that don't modify src or test files
revert
Reverts a previous commit
BREAKING!
Appending ! after type/scope signals a breaking API change (MAJOR in SemVer)
Writing Better Commit Messages
Why Commit Message Conventions Matter
Standardized commit messages make your git history scannable and enable powerful automation. Tools like semantic-release and standard-version use Conventional Commits to automatically determine version bumps and generate changelogs. A well-formatted commit history helps teammates understand changes without reading every diff.
Subject Line Best Practices
Use the imperative mood: write add validation not added validation. Keep the subject line under 72 characters. Do not end with a period. Separate the subject from the body with a blank line. The subject should complete the sentence: "If applied, this commit will your subject line."
When to Use the Body
Use the body to explain what changed and why, not how. The code diff already shows how. Wrap body lines at 72 characters. Reference related issues, discuss side effects, and provide context that future developers will need. Not every commit needs a body — simple changes like fixing a typo are self-explanatory.
Conventional Commits is a specification for writing standardized commit messages. The format is: type(scope): description. The type indicates the kind of change (feat, fix, docs, etc.), scope is optional and describes the affected area, and description is a short summary. This format enables automated changelog generation, semantic versioning, and makes git history easier to read.
What commit types are available in Conventional Commits?▼
The main types are: feat (new feature), fix (bug fix), docs (documentation), style (formatting), refactor (code restructuring), perf (performance), test (adding tests), build (build system), ci (CI config), chore (maintenance), and revert. Only feat and fix are required by the spec; the rest are recommended by the Angular convention.
How do I indicate a breaking change in a commit message?▼
Add an exclamation mark after the type/scope (e.g., feat!: or feat(api)!:) or add a BREAKING CHANGE: footer. Both signal backward-incompatible changes that trigger a major version bump in semantic versioning.
Why should the commit subject line be 72 characters or less?▼
The 72-character limit ensures commit messages display correctly in git log, GitHub, GitLab, and email notifications. It forces concise summaries. Use the commit body for detailed explanations, which has no character limit.
What is the difference between Conventional Commits and Gitmoji?▼
Conventional Commits uses text prefixes (feat:, fix:) while Gitmoji uses emoji characters (sparkles for features, bug for fixes). Both standardize commit messages, but Gitmoji adds visual scanning. Conventional Commits is more widely adopted in enterprise and open-source projects.
Keyboard Shortcuts
Ctrl+Enter Copy message Ctrl+Shift+C Copy git command Ctrl+L Clear all fields ? Toggle shortcuts help