| name | git-commit |
| description | Generates well-structured git commit messages following conventional commit standards and best practices. Creates clear, descriptive commits with proper type prefixes (feat, fix, docs, refactor, etc.), concise subjects, and detailed bodies when needed. Use when committing code changes, creating git commits, writing commit messages, or when users mention "commit", "git commit", "commit message", "conventional commits", "changelog", or need help structuring version control messages. Ensures commits are atomic, descriptive, and follow team conventions. |
Git Commit
Generates well-structured git commit messages following conventional commit standards and best practices.
Key Principles
- Be specific: Describe exactly what changed
- Be consistent: Follow conventional commit format
- Be atomic: One logical change per commit
- Be clear: Write for others (including future you)
- Be complete: Include why and context when needed
- Be conventional: Follow standard format for automation
Standard Format
<type>(<scope>): <subject>
<body>
<footer>
Components:
- type: Category of change (required) - feat, fix, docs, refactor, perf, test, build, ci, chore, style, revert
- scope: Area affected (optional) - auth, api, ui, db, etc.
- subject: Brief description (required, ≤50 chars)
- body: Detailed explanation (optional, wrap at 72 chars)
- footer: Breaking changes, issue refs (optional)
Basic Workflow
-
Choose the commit type:
feat: New user-facing functionalityfix: Bug fix for usersdocs: Documentation onlyrefactor: Code restructuring without behavior changeperf: Performance improvementtest: Adding/updating testsbuild: Dependency/build system changesci: CI/CD configuration changeschore: Maintenance tasksstyle: Code formattingrevert: Reverting previous commit
-
Write subject line (imperative mood, ≤50 chars):
✅ feat(auth): add OAuth2 authentication
✅ fix(api): resolve race condition in user updates
❌ feat: added some stuff
❌ fix: bug fix
-
Add body if needed (explain why, not just what):
- Required for breaking changes
- Recommended for complex changes
- Wrap lines at 72 characters
-
Include footer:
- Breaking changes:
BREAKING CHANGE: description
- Issue references:
Closes #123, Fixes #456
Quick Examples
Simple feature:
feat(auth): add password reset endpoint
Bug fix with context:
fix(api): prevent null pointer in user preferences
User preferences API crashed when optional fields were null.
Added null checks and default values.
Closes #456
Breaking change:
feat(api)!: change response format to JSON:API spec
BREAKING CHANGE: API responses now follow JSON:API format.
Update client code to parse data from `data` key instead
of root level.
Closes #789
Reference Documentation
For detailed guidance, load these reference files as needed:
