A conventional commit message follows a structured format that makes your git history readable and enables automated tooling like changelog generation and semantic versioning. This generator helps you build properly formatted commit messages by filling in type, scope, description, body, and footer fields, then validates the result against the Conventional Commits specification.
Build Your Commit
Preview
Your commit message will appear here...
Commit Type Examples
feat(auth): add OAuth2 login flow
New feature for the auth module
fix(api): handle null response body
Bug fix in the API layer
docs: update installation guide
Documentation-only change
refactor(parser): simplify token logic
Code restructuring, no behavior change
perf(db): add query result caching
Performance improvement
test(utils): add unit tests for helpers
Adding or updating tests
build(deps): upgrade webpack to v5
Build system or dependency update
ci: add staging deployment workflow
CI/CD configuration change
chore: update .gitignore patterns
Routine maintenance task
style(css): fix indentation in layout
Formatting change, no logic change
Based on the Conventional Commits v1.0.0 specification.
How to Use This Git Commit Message Generator
Writing consistent, well-structured git commit messages is one of the most impactful habits a developer can build. Good commit messages make your project history searchable, help teammates understand changes at a glance, and enable automated tools to generate changelogs, trigger releases, and enforce versioning rules. This generator follows the Conventional Commits specification to produce properly formatted messages every time.
Step 1: Choose a Commit Type
Select the type that best describes the purpose of your change. Use feat for new features that add functionality, fix for bug fixes, docs for documentation updates, refactor for code restructuring that does not change behavior, and perf for performance improvements. The type appears at the start of the commit message and tells tools and reviewers the nature of the change instantly.
Step 2: Add an Optional Scope
The scope narrows down which part of the codebase is affected. Common scopes include module names like auth, api, ui, or parser. This field is optional but highly recommended for larger projects where changes span multiple areas. The scope appears in parentheses after the type, like feat(auth).
Step 3: Write a Short Description
Enter a concise, imperative description of the change. The tool validates your description in real time: it should start with a lowercase letter, not end with a period, and stay under 72 characters total for the subject line. The character counter helps you stay within limits. Write descriptions as commands, like "add user login" rather than "added user login" or "adds user login."
Step 4: Add Body and Footer (Optional)
Use the body field to provide additional context, explain the motivation behind the change, or describe what was done and why. Toggle the breaking change switch if your commit introduces an incompatible change that requires users to update their code. The footer field is ideal for referencing issues, like "Closes #123" or "Refs #456," which many platforms use to automatically link and close issues.
Step 5: Copy Your Message
The preview panel shows your formatted conventional commit message in real time with syntax highlighting. Click the Copy button to copy the full message to your clipboard, then paste it directly into your terminal with git commit -m "..." or into your IDE's commit dialog. The generator handles all formatting, line breaks, and footer structure automatically.
FAQ
Is this git commit message generator free?
Yes, this tool is completely free to use with no limits. Generate as many commit messages as you need without creating an account or signing up. Everything runs locally in your browser.
Is my data safe when using this tool?
Absolutely. All processing happens entirely in your browser. No data is sent to any server. Your commit descriptions, scopes, and other inputs never leave your device.
What is the Conventional Commits specification?
Conventional Commits is a lightweight convention for structuring commit messages. It uses a format like 'type(scope): description' to make commit history readable and enable automated tooling like changelog generation, semantic versioning, and CI triggers. The specification is maintained at conventionalcommits.org.
What commit types are available and when should I use each?
The most common types are: feat (new features), fix (bug fixes), docs (documentation changes), style (formatting, no code change), refactor (code restructuring), perf (performance improvements), test (adding tests), build (build system changes), ci (CI configuration), chore (maintenance tasks), and revert (reverting previous commits). Choose the type that best describes the primary purpose of your change.
Why should my commit description start with a lowercase letter?
The Conventional Commits specification recommends lowercase descriptions for consistency across your commit history. Lowercase descriptions also work better with automated tools that generate changelogs and release notes, since the description follows the colon directly and reads more naturally in generated output.
What is a breaking change in a commit message?
A breaking change indicates that a commit introduces an incompatible API or behavior change. In Conventional Commits, you mark breaking changes with a 'BREAKING CHANGE:' footer or by adding an exclamation mark after the type and scope, like 'feat(api)!: description'. This signals to users and automated tools that the change requires migration steps.
How long should a git commit description be?
The subject line (type, scope, and description combined) should be under 72 characters. This limit ensures the message displays properly in terminal tools like git log, GitHub, and other interfaces. If you need more detail, use the optional body field to provide a longer explanation separated by a blank line.