|
| 1 | +# Claude Command: Commit |
| 2 | + |
| 3 | +This command helps you create well-formatted commits with conventional commit messages and emoji. |
| 4 | + |
| 5 | +## Usage |
| 6 | + |
| 7 | +To create a commit, just type: |
| 8 | +``` |
| 9 | +/commit |
| 10 | +``` |
| 11 | + |
| 12 | +Or with options: |
| 13 | +``` |
| 14 | +/commit --no-verify |
| 15 | +``` |
| 16 | + |
| 17 | +## What This Command Does |
| 18 | + |
| 19 | +1. Unless specified with `--no-verify`, automatically runs pre-commit checks: |
| 20 | + - `mise run check` |
| 21 | +2. Checks which files are staged with `git status` |
| 22 | +3. If 0 files are staged, automatically adds all modified and new files with `git add` |
| 23 | +4. Performs a `git diff` to understand what changes are being committed |
| 24 | +5. Analyzes the diff to determine if multiple distinct logical changes are present |
| 25 | +6. If multiple distinct changes are detected, suggests breaking the commit into multiple smaller commits |
| 26 | +7. For each commit (or the single commit if not split), creates a commit message using emoji conventional commit format |
| 27 | + |
| 28 | +## Best Practices for Commits |
| 29 | + |
| 30 | +- **Verify before committing**: Ensure code is linted, builds correctly, and documentation is updated |
| 31 | +- **Atomic commits**: Each commit should contain related changes that serve a single purpose |
| 32 | +- **Split large changes**: If changes touch multiple concerns, split them into separate commits |
| 33 | +- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature") |
| 34 | +- **Concise first line**: Keep the first line under 72 characters |
| 35 | + |
| 36 | +The commit message should be structured as follows: |
| 37 | + |
| 38 | +``` |
| 39 | +<type>[optional scope]: <description> |
| 40 | +[optional body] |
| 41 | +``` |
| 42 | + |
| 43 | +Where `type` is one of: |
| 44 | + - `feat`: A new feature |
| 45 | + - `fix`: A bug fix |
| 46 | + - `docs`: Documentation changes |
| 47 | + - `deps`: Dependency changes (crate versions, etc) |
| 48 | + - `style`: Code style changes (formatting, etc) |
| 49 | + - `refactor`: Code changes that neither fix bugs nor add features |
| 50 | + - `perf`: Performance improvements |
| 51 | + - `test`: Adding or fixing tests |
| 52 | + - `chore`: Changes to the build process, tools, etc. |
| 53 | + |
| 54 | +A `scope` MAY be provided after a type. A scope consist of a noun describing a section of the codebase surrounded by parenthesis `fix(parser)`. |
| 55 | + |
| 56 | + |
| 57 | +## Guidelines for Splitting Commits |
| 58 | + |
| 59 | +When analyzing the diff, consider splitting commits based on these criteria: |
| 60 | + |
| 61 | +1. **Different concerns**: Changes to unrelated parts of the codebase |
| 62 | +2. **Different types of changes**: Mixing features, fixes, refactoring, etc. |
| 63 | +3. **File patterns**: Changes to different types of files (e.g., source code vs documentation) |
| 64 | +4. **Logical grouping**: Changes that would be easier to understand or review separately |
| 65 | +5. **Size**: Very large changes that would be clearer if broken down |
| 66 | + |
| 67 | +## Examples |
| 68 | + |
| 69 | +Good commit messages: |
| 70 | +- feat: add user authentication system |
| 71 | +- fix: resolve memory leak in rendering process |
| 72 | +- docs: update API documentation with new endpoints |
| 73 | +- refactor: simplify error handling logic in parser |
| 74 | +- fix: resolve linter warnings in component files |
| 75 | +- chore: improve developer tooling setup process |
| 76 | +- feat: implement business logic for transaction validation |
| 77 | +- fix: address minor styling inconsistency in header |
| 78 | +- fix: patch critical security vulnerability in auth flow |
| 79 | +- style: reorganize component structure for better readability |
| 80 | +- fix: remove deprecated legacy code |
| 81 | +- feat: add input validation for user registration form |
| 82 | +- fix: resolve failing CI pipeline tests |
| 83 | +- feat: implement analytics tracking for user engagement |
| 84 | +- fix: strengthen authentication password requirements |
| 85 | +- feat: improve form accessibility for screen readers |
| 86 | + |
| 87 | +Example of splitting commits: |
| 88 | +- First commit: feat: add new solc version type definitions |
| 89 | +- Second commit: docs: update documentation for new solc versions |
| 90 | +- Third commit: chore: update package.json dependencies |
| 91 | +- Fourth commit: feat: add type definitions for new API endpoints |
| 92 | +- Fifth commit: feat: improve concurrency handling in worker threads |
| 93 | +- Sixth commit: fix: resolve linting issues in new code |
| 94 | +- Seventh commit: test: add unit tests for new solc version features |
| 95 | +- Eighth commit: fix: update dependencies with security vulnerabilities |
| 96 | + |
| 97 | +## Command Options |
| 98 | + |
| 99 | +- `--no-verify`: Skip running the pre-commit checks |
| 100 | + |
| 101 | +## Important Notes |
| 102 | + |
| 103 | +- By default, pre-commit checks (`mise run check`) will run to ensure code quality |
| 104 | +- If these checks fail, you'll be asked if you want to proceed with the commit anyway or fix the issues first |
| 105 | +- If specific files are already staged, the command will only commit those files |
| 106 | +- If no files are staged, it will automatically stage all modified and new files |
| 107 | +- The commit message will be constructed based on the changes detected |
| 108 | +- Before committing, the command will review the diff to identify if multiple commits would be more appropriate |
| 109 | +- If suggesting multiple commits, it will help you stage and commit the changes separately |
| 110 | +- Always reviews the commit diff to ensure the message matches the changes |
0 commit comments