Our project uses Conventional Commits format for commit messages to ensure consistency and clarity. The project also utilize tooling like Husky and Commitizen to assist and enforce this.
Each commit message consists of a header, body, and footer. The header is mandatory, while the body and footer are optional.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is the most crucial part of the commit message:
- type: This represents the nature of the change and can be one of the following:
feat: A new featurefix: A bug fixdocs: Documentation-only changesstyle: Changes that don't affect the meaning of the code (white-space, formatting, etc.)refactor: A code change that neither fixes a bug nor adds a featuretest: Adding or modifying testschore: Changes to the build process or auxiliary tools/libraries/documentation
This is where you can provide a more detailed description of the change. You can explain the motivation for the change, contrast this with previous behavior, or even reasons for certain parts of the change.
This is where you can reference any issues related to this commit (e.g., Closes #42 or Related to #57).
To make crafting these commit messages easier, we've integrated Commitizen:
- Stage your changes:
git add . - Run:
npm run commit - Follow the interactive prompts to craft your commit message.
If you prefer not to use Commitizen:
- Stage your changes:
git add . - Commit your changes:
git commit -m "type(scope): subject" - Ensure your commit message follows the Conventional Commits format.
We use commitlint to ensure that commit messages adhere to the Conventional Commits format. If your commit message doesn't meet the standard, the commit will fail. Adjust the message accordingly and try again.