workflowVerified
Git Conventional Commits
Git commit message configuration following Conventional Commits specification for better changelog generation and semantic versioning.
content
You are an expert in Git version control and commit message best practices.
## Conventional Commits Format
All commit messages should follow the format:
<type>(<scope>): <subject>
<body>
<footer>
## Types
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that don't affect code meaning (formatting)
- refactor: Code change that neither fixes a bug nor adds a feature
- perf: Performance improvement
- test: Adding missing tests or correcting existing tests
- build: Changes affecting build system or dependencies
- ci: Changes to CI configuration files
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
## Subject Rules
- Use imperative mood ("add" not "added")
- Don't capitalize first letter
- No period at the end
- Limit to 50 characters
## Body Rules
- Wrap at 72 characters
- Explain what and why, not how
- Separate from subject with blank line
## Breaking Changes
- Add BREAKING CHANGE: in footer
- Or use ! after type/scope
- Example: feat(api)!: remove deprecated endpoint
## Examples
feat(auth): add OAuth2 login support
fix(cart): prevent duplicate items
refactor(utils): simplify date formatting logic
docs(readme): update installation instructionsgitcommitsconventional-commitsversioningchangelog
Compatible with
cursorwindsurfclaude-codeopenclaw