Commandpython
/git-commit Command
Create well-formatted commits with conventional commit format and emoji
Smart Git Commit
Create well-formatted commit: $ARGUMENTS
Current Repository State
- Git status: !git status --porcelain
- Current branch: !git branch --show-current
- Staged changes: !git diff --cached --stat
- Unstaged changes: !git diff --stat
- Recent commits: !git log --oneline -5
What This Command Does
- Checks which files are staged with git status
- If 0 files are staged, automatically adds all modified and new files with git add
- Performs a git diff to understand what changes are being committed
- Analyzes the diff to determine if multiple distinct logical changes are present
- If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits
- For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format
Best Practices for Commits
- Verify before committing: Ensure code quality checks pass (hooks will run automatically)
- Atomic commits: Each commit should contain related changes that serve a single purpose
- Split large changes: If changes touch multiple concerns, split them into separate commits
- Conventional commit format: Use the format <type>: <description> where type is one of:
- feat: A new feature
- fix: A bug fix
- docs: Documentation changes
- style: Code style changes (formatting, etc)
- refactor: Code changes that neither fix bugs nor add features
- perf: Performance improvements
- test: Adding or fixing tests
- chore: Changes to the build process, tools, etc.
- Present tense, imperative mood: Write commit messages as commands (e.g., "add feature" not "added feature")
- Concise first line: Keep the first line under 72 characters
- Emoji: Each commit type is paired with an appropriate emoji:
- โจ feat: New feature
- ๐ fix: Bug fix
- ๐ docs: Documentation
- ๐ style: Formatting/style
- โป๏ธ refactor: Code refactoring
- โก๏ธ perf: Performance improvements
- โ test: Tests
- ๐ง chore: Tooling, configuration
- ๐ ci: CI/CD improvements
- ๐๏ธ revert: Reverting changes
- ๐งช test: Add a failing test
- ๐จ fix: Fix compiler/linter warnings
- ๐๏ธ fix: Fix security issues
- ๐ฅ chore: Add or update contributors
- ๐ refactor: Move or rename resources
- ๐๏ธ refactor: Make architectural changes
- ๐ chore: Merge branches
- ๐ฆ๏ธ chore: Add or update compiled files or packages
- โ chore: Add a dependency
- โ chore: Remove a dependency
- ๐ฑ chore: Add or update seed files
- ๐งโ๐ป chore: Improve developer experience
- ๐งต feat: Add or update code related to multithreading or concurrency
- ๐๏ธ feat: Improve SEO
- ๐ท๏ธ feat: Add or update types
- ๐ฌ feat: Add or update text and literals
- ๐ feat: Internationalization and localization
- ๐ feat: Add or update business logic
- ๐ฑ feat: Work on responsive design
- ๐ธ feat: Improve user experience / usability
- ๐ฉน fix: Simple fix for a non-critical issue
- ๐ฅ fix: Catch errors
- ๐ฝ๏ธ fix: Update code due to external API changes
- ๐ฅ fix: Remove code or files
- ๐จ style: Improve structure/format of the code
- ๐๏ธ fix: Critical hotfix
- ๐ chore: Begin a project
- ๐ chore: Release/Version tags
- ๐ง wip: Work in progress
- ๐ fix: Fix CI build
- ๐ chore: Pin dependencies to specific versions
- ๐ท ci: Add or update CI build system
- ๐ feat: Add or update analytics or tracking code
- โ๏ธ fix: Fix typos
- โช๏ธ revert: Revert changes
- ๐ chore: Add or update license
- ๐ฅ feat: Introduce breaking changes
- ๐ฑ assets: Add or update assets
- โฟ๏ธ feat: Improve accessibility
- ๐ก docs: Add or update comments in source code
- ๐๏ธ db: Perform database related changes
- ๐ feat: Add or update logs
- ๐ fix: Remove logs
- ๐คก test: Mock things
- ๐ฅ feat: Add or update an easter egg
- ๐ chore: Add or update .gitignore file
- ๐ธ test: Add or update snapshots
- โ๏ธ experiment: Perform experiments
- ๐ฉ feat: Add, update, or remove feature flags
- ๐ซ ui: Add or update animations and transitions
- โฐ๏ธ refactor: Remove dead code
- ๐ฆบ feat: Add or update code related to validation
- โ๏ธ feat: Improve offline support
Guidelines for Splitting Commits
When analyzing the diff, consider splitting commits based on these criteria:
- Different concerns: Changes to unrelated parts of the codebase
- Different types of changes: Mixing features, fixes, refactoring, etc.
- File patterns: Changes to different types of files (e.g., source code vs documentation)
- Logical grouping: Changes that would be easier to understand or review separately
- Size: Very large changes that would be clearer if broken down
Examples
Good commit messages:
- โจ feat: add user authentication system
- ๐ fix: resolve memory leak in rendering process
- ๐ docs: update API documentation with new endpoints
- โป๏ธ refactor: simplify error handling logic in parser
- ๐จ fix: resolve linter warnings in component files
- ๐งโ๐ป chore: improve developer tooling setup process
- ๐ feat: implement business logic for transaction validation
- ๐ฉน fix: address minor styling inconsistency in header
- ๐๏ธ fix: patch critical security vulnerability in auth flow
- ๐จ style: reorganize component structure for better readability
- ๐ฅ fix: remove deprecated legacy code
- ๐ฆบ feat: add input validation for user registration form
- ๐ fix: resolve failing CI pipeline tests
- ๐ feat: implement analytics tracking for user engagement
- ๐๏ธ fix: strengthen authentication password requirements
- โฟ๏ธ feat: improve form accessibility for screen readers
Example of splitting commits:
- First commit: โจ feat: add new solc version type definitions
- Second commit: ๐ docs: update documentation for new solc versions
- Third commit: ๐ง chore: update package.json dependencies
- Fourth commit: ๐ท๏ธ feat: add type definitions for new API endpoints
- Fifth commit: ๐งต feat: improve concurrency handling in worker threads
- Sixth commit: ๐จ fix: resolve linting issues in new code
- Seventh commit: โ test: add unit tests for new solc version features
- Eighth commit: ๐๏ธ fix: update dependencies with security vulnerabilities
Command Options
- --amend: Amend the previous commit instead of creating a new one
Important Notes
- Git hooks configured in
.claude/settings.jsonwill run automatically during commit - If hooks block the commit, you'll need to fix the issues before proceeding
- If specific files are already staged, the command will only commit those files
- If no files are staged, it will automatically stage all modified and new files
- The commit message will be constructed based on the changes detected
- Before committing, the command will review the diff to identify if multiple commits would be more appropriate
- If suggesting multiple commits, it will help you stage and commit the changes separately
- Always reviews the commit diff to ensure the message matches the changes