|
| 1 | +# Commiting Guidelines |
| 2 | + |
| 3 | +## Commit Structure |
| 4 | + |
| 5 | +- **Make Commits Atomic**: Each commit should represent a single logical change. Avoid mixing multiple changes in a single commit. If a change affects multiple files, ensure it constitutes one "logical" change. |
| 6 | + |
| 7 | +### Writing Commit Messages |
| 8 | + |
| 9 | +- **Clear Subject Line**: Start the commit message with a clear and concise description of the change. It should be no more than 50 characters, start with a capital letter, and be in imperative mood. |
| 10 | + |
| 11 | + - > ```bash |
| 12 | + > feat: Add function to calculate average |
| 13 | + > ``` |
| 14 | +
|
| 15 | +- **Separate Subject from Body**: If further explanation is needed, include it in the body of the commit message, following a blank line after the subject line. |
| 16 | +
|
| 17 | +- **Explain the Change**: The body of the commit message should explain why the change was needed and how it was implemented. Keep it wrapped to 72 characters and written in present tense. |
| 18 | +
|
| 19 | + - > ```bash |
| 20 | + > fix: Resolve issue with login form not submitting on Safari |
| 21 | + > |
| 22 | + > This commit fixes a bug where the login form was not submitting on Safari browsers. The issue was caused by an outdated event listener binding, which has been updated to the correct syntax. |
| 23 | + > ``` |
| 24 | +
|
| 25 | +- **Avoid "How" Details**: Use the commit message to explain what changes were made and why, not how they were made. Well-written code should be self-explanatory. |
| 26 | +
|
| 27 | +- **Reference Issues or Pull Requests**: If the commit is related to an issue or a pull request, include the reference in the commit message. This can be done in the body of the message or at the end. |
| 28 | +
|
| 29 | + - > ```bash |
| 30 | + > feat: Add user authentication feature |
| 31 | + > |
| 32 | + > Closes #123 |
| 33 | + > ``` |
| 34 | +
|
| 35 | +- **Avoid Unnecessary Punctuation**: Do not end the subject line with a period. |
| 36 | +
|
| 37 | +### Commit Message Structure Rules |
| 38 | +
|
| 39 | +- **Type Enum**: Ensure your commit type matches one of the predefined values: `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`. |
| 40 | +
|
| 41 | + - `build`: This type is used for changes related to build processes or tools. It includes modifications to build scripts, configuration files, and build-related dependencies. |
| 42 | +
|
| 43 | + - `chore`: Chore changes typically involve tasks related to maintenance or housekeeping. This could include updating dependencies, cleaning up code, or configuring development tools. |
| 44 | +
|
| 45 | + - `ci`: Changes related to Continuous Integration (CI) configuration files and scripts fall under this type. It includes modifications to CI pipelines, configurations for automated testing, and integration with CI services. |
| 46 | +
|
| 47 | + - `docs`: Documentation changes belong to this type. It covers updates to documentation files, such as READMEs, API documentation, or inline code comments. |
| 48 | +
|
| 49 | + - `feat`: This type is for new feature implementations or enhancements to existing features. It signifies significant additions or improvements to the codebase's functionality. |
| 50 | +
|
| 51 | + - `fix`: Use this type for bug fixes or patches. It indicates changes made to address issues or bugs in the codebase. |
| 52 | +
|
| 53 | + - `perf`: Performance-related changes are categorized under this type. It includes optimizations aimed at improving the codebase's performance, such as reducing execution time or memory usage. |
| 54 | +
|
| 55 | + - `refactor`: Refactoring changes fall under this type. It involves restructuring or cleaning up the code without changing its external behavior. Refactoring aims to improve code quality, maintainability, or readability. |
| 56 | +
|
| 57 | + - `revert`: Reverting changes made in a previous commit is indicated by this type. It's used when undoing the effects of a specific commit, often to address unexpected issues or regressions introduced by the previous change. |
| 58 | +
|
| 59 | + - `style`: Style-related changes belong to this type. It covers modifications to code style, formatting, or whitespace, without affecting the code's functionality. |
| 60 | +
|
| 61 | + - `test`: Test-related changes are categorized under this type. It includes additions or modifications to test cases, test suites, or testing infrastructure to ensure code correctness and reliability. |
| 62 | +
|
| 63 | +- **Type Case**: Use lowercase for commit types. |
| 64 | +
|
| 65 | +- **Subject Not Empty**: The subject line should not be empty. |
| 66 | +
|
| 67 | +- **Subject Case**: Use sentence case for the subject line. |
| 68 | +
|
| 69 | +- **Subject Length**: Keep the subject line under 100 characters. |
| 70 | +
|
| 71 | +- **Body Leading Blank**: Ensure there's a leading blank line in the commit body. |
| 72 | +
|
| 73 | +- **Body Max Line Length**: Keep each line in the commit body under 100 characters. |
0 commit comments