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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: git-commit-313description: 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---56# Git Commit78Generates well-structured git commit messages following conventional commit standards and best practices.910## Key Principles11121. **Be specific**: Describe exactly what changed132. **Be consistent**: Follow conventional commit format143. **Be atomic**: One logical change per commit154. **Be clear**: Write for others (including future you)165. **Be complete**: Include why and context when needed176. **Be conventional**: Follow standard format for automation1819## Standard Format2021```22<type>(<scope>): <subject>2324<body>2526<footer>27```2829**Components:**3031- **type**: Category of change (required) - feat, fix, docs, refactor, perf, test, build, ci, chore, style, revert32- **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)3637## Basic Workflow38391. **Choose the commit type**:40 - `feat`: New user-facing functionality41 - `fix`: Bug fix for users42 - `docs`: Documentation only43 - `refactor`: Code restructuring without behavior change44 - `perf`: Performance improvement45 - `test`: Adding/updating tests46 - `build`: Dependency/build system changes47 - `ci`: CI/CD configuration changes48 - `chore`: Maintenance tasks49 - `style`: Code formatting50 - `revert`: Reverting previous commit51522. **Write subject line** (imperative mood, ≤50 chars):5354 ```55 ✅ feat(auth): add OAuth2 authentication56 ✅ fix(api): resolve race condition in user updates57 ❌ feat: added some stuff58 ❌ fix: bug fix59 ```60613. **Add body if needed** (explain why, not just what):62 - Required for breaking changes63 - Recommended for complex changes64 - Wrap lines at 72 characters65664. **Include footer**:67 - Breaking changes: `BREAKING CHANGE: description`68 - Issue references: `Closes #123`, `Fixes #456`6970## Quick Examples7172**Simple feature:**7374```75feat(auth): add password reset endpoint76```7778**Bug fix with context:**7980```81fix(api): prevent null pointer in user preferences8283User preferences API crashed when optional fields were null.84Added null checks and default values.8586Closes #45687```8889**Breaking change:**9091```92feat(api)!: change response format to JSON:API spec9394BREAKING CHANGE: API responses now follow JSON:API format.95Update client code to parse data from `data` key instead96of root level.9798Closes #78999```100101## Reference Documentation102103For detailed guidance, load these reference files as needed:104105- **[commit-types.md](references/commit-types.md)**: Complete list of commit types with examples106- **[quick-reference.md](references/quick-reference.md)**: Decision trees and checklists107- **[best-practices.md](references/best-practices.md)**: Atomic commits, meaningful messages, issue references108- **[writing-guidelines.md](references/writing-guidelines.md)**: Subject line rules, scope selection, body formatting109- **[common-scenarios.md](references/common-scenarios.md)**: Examples for typical development situations110- **[common-mistakes-to-avoid.md](references/common-mistakes-to-avoid.md)**: Anti-patterns and how to fix them111- **[team-conventions.md](references/team-conventions.md)**: Customizing conventions for teams112- **[commit-message-structure.md](references/commit-message-structure.md)**: Detailed format specifications113- **[commit-message-templates.md](references/commit-message-templates.md)**: Ready-to-use templates114- **[commit-workflow.md](references/commit-workflow.md)**: Integration with git workflows115- **[examples-by-project-type.md](references/examples-by-project-type.md)**: Examples for web apps, libraries, mobile, microservices116- **[advanced-patterns.md](references/advanced-patterns.md)**: Complex scenarios and edge cases117- **[commit-message-convention.md](references/commit-message-convention.md)**: Enforcement tools and configurations118119---120> Converted and distributed by [TomeVault](https://tomevault.io/claim/dauquangthanh) — claim your Tome and manage your conversions.121<!-- tomevault:4.0:skill_md:2026-04-11 -->
tomevault-io