Format:
Actions:
Commit Details
0/72 characters
Summary is required
Explain what and why, not how
Live Preview
Fill in the required fields to see the preview
Fill in the details to generate a commit message...
About Conventional Commits
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of.
Commit Message Format
<type>(<scope>): <subject> <body> <footer>
Benefits
- Automatically generate CHANGELOGs
- Automatically determine semantic version bumps
- Communicate the nature of changes to teammates and stakeholders
- Trigger build and publish processes
- Make it easier for people to contribute by allowing them to explore a more structured commit history
Common Types
✨
feat — A new feature
🐛
fix — A bug fix
📚
docs — Documentation only changes
💎
style — Code style changes (formatting, etc)
♻️
refactor — Code refactoring
✅
test — Adding or updating tests
Footer Usage
The footer is optional and contains metadata about the commit. Common use cases include:
Breaking Changes: Use
BREAKING CHANGE: to indicate incompatible API changes. This will trigger a major version bump in semantic versioning.BREAKING CHANGE: API endpoints now require authentication Users must update their API clients to include auth tokens
Issue References: Link commits to issue trackers using keywords like
Closes, Fixes, or Resolves.Closes #123 Fixes #456, #789
Co-authors & Reviewers: Credit contributors and reviewers in the commit.
Co-authored-by: John Doe <john@example.com> Reviewed-by: Jane Smith <jane@example.com>