216 lines
4.4 KiB
Markdown
216 lines
4.4 KiB
Markdown
---
|
|
name: Git Commit Helper
|
|
description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.
|
|
---
|
|
|
|
# Git Commit Helper
|
|
|
|
## Quick start
|
|
|
|
Analyze staged changes and generate commit message:
|
|
|
|
```bash
|
|
# View staged changes
|
|
git diff --staged
|
|
|
|
# Generate commit message based on changes
|
|
# (Claude will analyze the diff and suggest a message)
|
|
```
|
|
|
|
## Commit message format
|
|
|
|
Follow conventional commits format:
|
|
|
|
```
|
|
<type>(<scope>): <description>
|
|
|
|
[optional body]
|
|
|
|
[optional footer]
|
|
```
|
|
|
|
### Types
|
|
|
|
- **feat**: New feature
|
|
- **fix**: Bug fix
|
|
- **docs**: Documentation changes
|
|
- **style**: Code style changes (formatting, missing semicolons)
|
|
- **refactor**: Code refactoring
|
|
- **test**: Adding or updating tests
|
|
- **chore**: Maintenance tasks
|
|
|
|
### Examples
|
|
|
|
**Feature commit:**
|
|
|
|
```
|
|
feat(auth): add JWT authentication
|
|
|
|
Implement JWT-based authentication system with:
|
|
- Login endpoint with token generation
|
|
- Token validation middleware
|
|
- Refresh token support
|
|
```
|
|
|
|
**Bug fix:**
|
|
|
|
```
|
|
fix(api): handle null values in user profile
|
|
|
|
Prevent crashes when user profile fields are null.
|
|
Add null checks before accessing nested properties.
|
|
```
|
|
|
|
**Refactor:**
|
|
|
|
```
|
|
refactor(database): simplify query builder
|
|
|
|
Extract common query patterns into reusable functions.
|
|
Reduce code duplication in database layer.
|
|
```
|
|
|
|
## Analyzing changes
|
|
|
|
Review what's being committed:
|
|
|
|
```bash
|
|
# Show files changed
|
|
git status
|
|
|
|
# Show detailed changes
|
|
git diff --staged
|
|
|
|
# Show statistics
|
|
git diff --staged --stat
|
|
|
|
# Show changes for specific file
|
|
git diff --staged path/to/file
|
|
```
|
|
|
|
## Commit message guidelines
|
|
|
|
**DO:**
|
|
|
|
- Use imperative mood ("add feature" not "added feature")
|
|
- Keep first line under 50 characters
|
|
- Capitalize first letter
|
|
- No period at end of summary
|
|
- Explain WHY not just WHAT in body
|
|
|
|
**DON'T:**
|
|
|
|
- Use vague messages like "update" or "fix stuff"
|
|
- Include technical implementation details in summary
|
|
- Write paragraphs in summary line
|
|
- Use past tense
|
|
|
|
## Multi-file commits
|
|
|
|
When committing multiple related changes:
|
|
|
|
```
|
|
refactor(core): restructure authentication module
|
|
|
|
- Move auth logic from controllers to service layer
|
|
- Extract validation into separate validators
|
|
- Update tests to use new structure
|
|
- Add integration tests for auth flow
|
|
|
|
Breaking change: Auth service now requires config object
|
|
```
|
|
|
|
## Scope examples
|
|
|
|
**Frontend:**
|
|
|
|
- `feat(ui): add loading spinner to dashboard`
|
|
- `fix(form): validate email format`
|
|
|
|
**Backend:**
|
|
|
|
- `feat(api): add user profile endpoint`
|
|
- `fix(db): resolve connection pool leak`
|
|
|
|
**Infrastructure:**
|
|
|
|
- `chore(ci): update Node version to 20`
|
|
- `feat(docker): add multi-stage build`
|
|
|
|
## Breaking changes
|
|
|
|
Indicate breaking changes clearly:
|
|
|
|
```
|
|
feat(api)!: restructure API response format
|
|
|
|
BREAKING CHANGE: All API responses now follow JSON:API spec
|
|
|
|
Previous format:
|
|
{ "data": {...}, "status": "ok" }
|
|
|
|
New format:
|
|
{ "data": {...}, "meta": {...} }
|
|
|
|
Migration guide: Update client code to handle new response structure
|
|
```
|
|
|
|
## Template workflow
|
|
|
|
Before you start drafting, read the full text of a few recent commits
|
|
(e.g., `git log -5`) so you can mirror the repository's tone and level of
|
|
detail.
|
|
|
|
1. **Review changes**: `git diff --staged`
|
|
2. **Identify type**: Is it feat, fix, refactor, etc.?
|
|
3. **Determine scope**: What part of the codebase?
|
|
4. **Write summary**: Brief, imperative description
|
|
5. **Add body**: Explain why and what impact
|
|
6. **Note breaking changes**: If applicable
|
|
|
|
## Interactive commit helper
|
|
|
|
Use `git add -p` for selective staging:
|
|
|
|
```bash
|
|
# Stage changes interactively
|
|
git add -p
|
|
|
|
# Review what's staged
|
|
git diff --staged
|
|
|
|
# Commit with message
|
|
git commit -m "type(scope): description"
|
|
```
|
|
|
|
## Amending commits
|
|
|
|
Fix the last commit message:
|
|
|
|
```bash
|
|
# Amend commit message only
|
|
git commit --amend
|
|
|
|
# Amend and add more changes
|
|
git add forgotten-file.js
|
|
git commit --amend --no-edit
|
|
```
|
|
|
|
## Best practices
|
|
|
|
1. **Atomic commits** - One logical change per commit
|
|
2. **Test before commit** - Ensure code works
|
|
3. **Reference issues** - Include issue numbers if applicable
|
|
4. **Keep it focused** - Don't mix unrelated changes
|
|
5. **Write for humans** - Future you will read this
|
|
|
|
## Commit message checklist
|
|
|
|
- [ ] Type is appropriate (feat/fix/docs/etc.)
|
|
- [ ] Scope is specific and clear
|
|
- [ ] Summary is under 50 characters
|
|
- [ ] Summary uses imperative mood
|
|
- [ ] Body explains WHY not just WHAT
|
|
- [ ] Breaking changes are clearly marked
|
|
- [ ] Related issue numbers are included
|