Commit Message Generator
Generate Conventional Commits messages with type, scope, breaking change, and issue reference. Copies as git commit command.
Number only, #123, Closes #123, etc. Separate multiple with comma or newline.
Type ✅ / Subject (required) ❌ / Body ✅ / Issue number ✅ / Scope ✅
Score: 75/100
Enter Subject to see the message update in real time
How to use
About this tool
Generate Conventional Commits messages with type, scope, breaking change, and issue reference. Copies as git commit command.
How to use
Enter Type and Subject (required); add Scope, Body, Breaking Change, and Issue as needed. Once Subject is entered, the message, Git command, and preview (Title/Body/Footer) update in real time. Validation and character counts (Subject 50, Body 72 per line) update as you type. Use each block's copy button to copy.
Options
Type: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert. Scope: alphanumeric, hyphen, underscore recommended. Subject: ≤50 chars, start lowercase, no trailing period. Issue: #123, Closes #123, Fixes #123, Resolves #123. Preview labels: English or Japanese.
Use cases
• Auto-generating release notes (grouped by type) • Enforcing team commit conventions • Explicit BREAKING CHANGE and issue references • Easier history search and filtering
How it works
Builds the first line as type(scope): subject or type: subject, then appends Body and Footer (BREAKING CHANGE, Closes #n, etc.). git commit: single -m "..." when no newlines; otherwise one -m "..." per line with escaping.
Privacy and data
All processing is done in the browser; no input or generated messages are sent to any server.
FAQ
- Q: What is Conventional Commits format?
- A: Conventional Commits is a specification for commit message structure: type(scope): subject. Common types are feat (new feature), fix (bug fix), docs, style, refactor, perf, test, build, ci, chore, and revert. This format enables automated changelog generation and semantic versioning.
- Q: What are breaking changes and how do I flag them?
- A: A breaking change is a commit that changes the public API incompatibly with prior versions. Add "BREAKING CHANGE:" in the footer or append ! after the type (e.g. feat!: remove legacy endpoint). This signals a major version bump in semantic versioning.
- Q: What should go in the Subject vs Body?
- A: Subject (≤50 chars): a concise summary in imperative mood — "add login button", not "added". Body: detailed explanation of what changed and why, wrapped at 72 characters per line. The body is optional but recommended for non-trivial changes.
- Q: How do I reference an issue or pull request?
- A: Use the Issue field with formats like #123, Closes #123, Fixes #123, or Resolves #123. These are placed in the commit footer and may automatically close the referenced issue on GitHub/GitLab when merged.
- Q: Does this tool send my commit message to a server?
- A: No. All processing is done entirely in the browser. Your input and generated messages are never sent to any server.
