| name | git-helper |
| description | Generate clear, conventional commit messages and manage Git workflows |
| allowed-tools | ["Bash","Read","Grep"] |
| origin | bundled |
| version | 1.0.0 |
Git Helper
Generate clear, conventional commit messages and assist with Git workflows following best practices.
When to Activate
Explicit Triggers
- User says "commit this"
- User says "生成提交信息"
- User says "write commit message"
- User says "git commit"
Implicit Triggers
- User completes changes and mentions committing
- User asks about Git workflow
- User needs help with commit messages
NOT Activated For
- Git configuration setup
- Merge conflict resolution
- Branch management (unless commit-related)
Commit Message Format
Conventional Commits Structure
<type>(<scope>): <subject>
<body>
<footer>
Types
- feat: New feature
- fix: Bug fix
- refactor: Code restructuring without behavior change
- docs: Documentation changes
- test: Adding or updating tests
- chore: Maintenance tasks (dependencies, build config)
- perf: Performance improvements
- ci: CI/CD configuration changes
- style: Code formatting (no logic change)
Examples
Good Commit Messages:
feat(auth): add JWT token refresh mechanism
Implement automatic token refresh when access token expires.
Tokens are refreshed 5 minutes before expiration to prevent
authentication failures during active sessions.
- Add RefreshTokenService
- Update AuthMiddleware to handle token refresh
- Add unit tests for refresh logic
Closes #123
fix(api): prevent SQL injection in user search
Replace string concatenation with parameterized queries
in UserRepository.search() method.
BREAKING CHANGE: search() now requires SearchParams object
instead of raw string query.
refactor(utils): extract retry logic into separate module
Move retry logic from multiple services into shared
RetryHelper utility to reduce code duplication.
Bad Commit Messages:
update stuff
fix bug
WIP
Commit Message Guidelines
Subject Line (First Line)
- Length: 50 characters or less
- Capitalization: Lowercase type, lowercase subject
- Tense: Imperative mood ("add" not "added" or "adds")
- No period: Don't end with a period
Body (Optional)
- Length: Wrap at 72 characters
- Content: Explain WHAT and WHY, not HOW
- Bullet points: Use
- or * for lists
Footer (Optional)
- Breaking changes:
BREAKING CHANGE: description
- Issue references:
Closes #123, Fixes #456
- Co-authors:
Co-authored-by: Name <email>
Git Workflow Best Practices
Before Committing
- Review changes
git status
git diff
- Stage selectively
git add -p
git add specific-file.ts
- Run tests
npm test
- Check linting
npm run lint
Commit Checklist
Atomic Commits
Good: One logical change per commit
git commit -m "feat(auth): add login endpoint"
git commit -m "test(auth): add login endpoint tests"
git commit -m "docs(auth): document login API"
Bad: Multiple unrelated changes
git commit -m "add login, fix bug in profile, update README"
Common Git Operations
Amend Last Commit
git commit --amend -m "new message"
git add forgotten-file.ts
git commit --amend --no-edit
Interactive Rebase
git rebase -i HEAD~3
Stash Changes
git stash save "WIP: feature description"
git stash list
git stash pop
Cherry-pick
git cherry-pick <commit-hash>
Branch Naming Conventions
Format: <type>/<short-description>
Examples:
feat/user-authentication
fix/login-validation-bug
refactor/database-layer
docs/api-documentation
Pull Request Workflow
Before Creating PR
- Update from main
git checkout main
git pull
git checkout feature-branch
git rebase main
- Squash if needed
git rebase -i main
- Push to remote
git push origin feature-branch
git push --force-with-lease origin feature-branch
PR Description Template
## Description
Brief description of changes
## Changes
- Change 1
- Change 2
- Change 3
## Testing
- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] Manual testing completed
## Related Issues
Closes #123
Commit Message Generation Process
-
Analyze changes
- Read
git diff --staged
- Identify modified files and functions
- Understand the purpose of changes
-
Determine type
- New feature →
feat
- Bug fix →
fix
- Refactoring →
refactor
- etc.
-
Identify scope
- Module/component affected
- Keep it short and clear
-
Write subject
- Imperative mood
- Clear and concise
- Under 50 characters
-
Add body if needed
- Explain complex changes
- Provide context
- List major modifications
Related Resources
- Follow conventional commits specification
- Keep commits atomic and focused
- Write clear, descriptive messages
- Use interactive rebase to clean history before PR