Conventional Commits Format
The commit message should be structured as follows:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]<type>(mandatory): A noun describing the type of change. The most common types arefeatfor new features andfixfor bug fixes, which directly correlate to semantic versioning (MINOR and PATCH, respectively). Other common types include:build: Changes affecting the build system or external dependencies.chore: Routine tasks and non-production code changes.ci: Changes to CI configuration files and scripts.docs: Documentation-only changes.style: Code style changes (whitespace, formatting, etc.).refactor: Code changes that neither fix a bug nor add a feature.perf: A code change that improves performance.test: Adding missing tests or correcting existing tests.feat: Adds a new feature (triggers a MINOR version bump).fix: Patches a bug (triggers a PATCH version bump).docs: Documentation-only changes.style: Changes that don’t affect code meaning (white-space, formatting, etc.).
[optional scope]: A parenthesized phrase that can be added after the type to describe a section of the codebase (e.g.,fix(parser): ...).<description>(mandatory): A short, imperative-mood description of the code changes (e.g., “fix: resolve issue with pagination” not “fixed issues with pagination”). The summary line is typically limited to 50 characters.[optional body]: A longer, detailed explanation of the changes, their motivation, and how they contrast with previous behavior. It should be separated from the description by a blank line and use the imperative, present tense.[optional footer(s)]: Provides additional meta-information, such as issue references (e.g.,Closes #123). Breaking changes can also be indicated here.