|
75 | 75 | - Start with an initial commit of functional changes
|
76 | 76 | - Follow with separate commits for formatting, linting, and type checking fixes
|
77 | 77 | </git_workflow>
|
| 78 | + |
| 79 | +<git_commit_standards> |
| 80 | +- Use the following commit message format: |
| 81 | + ``` |
| 82 | + Component/File(commit-type[Subcomponent/method]): Concise description |
| 83 | + |
| 84 | + why: Explanation of necessity or impact. |
| 85 | + what: |
| 86 | + - Specific technical changes made |
| 87 | + - Focused on a single topic |
| 88 | + |
| 89 | + refs: #issue-number, breaking changes, or relevant links |
| 90 | + ``` |
| 91 | + |
| 92 | +- Common commit types: |
| 93 | + - **feat**: New features or enhancements |
| 94 | + - **fix**: Bug fixes |
| 95 | + - **refactor**: Code restructuring without functional change |
| 96 | + - **docs**: Documentation updates |
| 97 | + - **chore**: Maintenance (dependencies, tooling, config) |
| 98 | + - **test**: Test-related updates |
| 99 | + - **style**: Code style and formatting |
| 100 | + |
| 101 | +- Prefix Python package changes with: |
| 102 | + - `py(deps):` for standard packages |
| 103 | + - `py(deps[dev]):` for development packages |
| 104 | + - `py(deps[extra]):` for extras/sub-packages |
| 105 | + |
| 106 | +- General guidelines: |
| 107 | + - Subject line: Maximum 50 characters |
| 108 | + - Body lines: Maximum 72 characters |
| 109 | + - Use imperative mood (e.g., "Add", "Fix", not "Added", "Fixed") |
| 110 | + - Limit to one topic per commit |
| 111 | + - Separate subject from body with a blank line |
| 112 | + - Mark breaking changes clearly: `BREAKING:` |
| 113 | +</git_commit_standards> |
0 commit comments