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:
- commit-types.md: Complete list of commit types with examples
- quick-reference.md: Decision trees and checklists
- best-practices.md: Atomic commits, meaningful messages, issue references
- writing-guidelines.md: Subject line rules, scope selection, body formatting
- common-scenarios.md: Examples for typical development situations
- common-mistakes-to-avoid.md: Anti-patterns and how to fix them
- team-conventions.md: Customizing conventions for teams
- commit-message-structure.md: Detailed format specifications
- commit-message-templates.md: Ready-to-use templates
- commit-workflow.md: Integration with git workflows
- examples-by-project-type.md: Examples for web apps, libraries, mobile, microservices
- advanced-patterns.md: Complex scenarios and edge cases
- commit-message-convention.md: Enforcement tools and configurations
1---2name: git-commit3description: 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.4---5
6# Git Commit
7
8Generates well-structured git commit messages following conventional commit standards and best practices.
9
10## Key Principles
11
121. **Be specific**: Describe exactly what changed
132. **Be consistent**: Follow conventional commit format
143. **Be atomic**: One logical change per commit
154. **Be clear**: Write for others (including future you)
165. **Be complete**: Include why and context when needed
176. **Be conventional**: Follow standard format for automation
18
19## Standard Format
20
21```
22<type>(<scope>): <subject>
23
24<body>
25
26<footer>
27```
28
29**Components:**
30
31- **type**: Category of change (required) - feat, fix, docs, refactor, perf, test, build, ci, chore, style, revert
32- **scope**: Area affected (optional) - auth, api, ui, db, etc.
33- **subject**: Brief description (required, ≤50 chars)
34- **body**: Detailed explanation (optional, wrap at 72 chars)
35- **footer**: Breaking changes, issue refs (optional)
36
37## Basic Workflow
38
391. **Choose the commit type**:
40 - `feat`: New user-facing functionality
41 - `fix`: Bug fix for users
42 - `docs`: Documentation only
43 - `refactor`: Code restructuring without behavior change
44 - `perf`: Performance improvement
45 - `test`: Adding/updating tests
46 - `build`: Dependency/build system changes
47 - `ci`: CI/CD configuration changes
48 - `chore`: Maintenance tasks
49 - `style`: Code formatting
50 - `revert`: Reverting previous commit
51
522. **Write subject line** (imperative mood, ≤50 chars):
53
54 ```
55 ✅ feat(auth): add OAuth2 authentication
56 ✅ fix(api): resolve race condition in user updates
57 ❌ feat: added some stuff
58 ❌ fix: bug fix
59 ```
60
613. **Add body if needed** (explain why, not just what):
62 - Required for breaking changes
63 - Recommended for complex changes
64 - Wrap lines at 72 characters
65
664. **Include footer**:
67 - Breaking changes: `BREAKING CHANGE: description`
68 - Issue references: `Closes #123`, `Fixes #456`
69
70## Quick Examples
71
72**Simple feature:**
73
74```
75feat(auth): add password reset endpoint
76```
77
78**Bug fix with context:**
79
80```
81fix(api): prevent null pointer in user preferences
82
83User preferences API crashed when optional fields were null.
84Added null checks and default values.
85
86Closes #456
87```
88
89**Breaking change:**
90
91```
92feat(api)!: change response format to JSON:API spec
93
94BREAKING CHANGE: API responses now follow JSON:API format.
95Update client code to parse data from `data` key instead
96of root level.
97
98Closes #789
99```
100
101## Reference Documentation
102
103For detailed guidance, load these reference files as needed:
104
105- **[commit-types.md](references/commit-types.md)**: Complete list of commit types with examples
106- **[quick-reference.md](references/quick-reference.md)**: Decision trees and checklists
107- **[best-practices.md](references/best-practices.md)**: Atomic commits, meaningful messages, issue references
108- **[writing-guidelines.md](references/writing-guidelines.md)**: Subject line rules, scope selection, body formatting
109- **[common-scenarios.md](references/common-scenarios.md)**: Examples for typical development situations
110- **[common-mistakes-to-avoid.md](references/common-mistakes-to-avoid.md)**: Anti-patterns and how to fix them
111- **[team-conventions.md](references/team-conventions.md)**: Customizing conventions for teams
112- **[commit-message-structure.md](references/commit-message-structure.md)**: Detailed format specifications
113- **[commit-message-templates.md](references/commit-message-templates.md)**: Ready-to-use templates
114- **[commit-workflow.md](references/commit-workflow.md)**: Integration with git workflows
115- **[examples-by-project-type.md](references/examples-by-project-type.md)**: Examples for web apps, libraries, mobile, microservices
116- **[advanced-patterns.md](references/advanced-patterns.md)**: Complex scenarios and edge cases
117- **[commit-message-convention.md](references/commit-message-convention.md)**: Enforcement tools and configurations
dauquangthanh