Commit Convention¶

Using structured commit messages, we can enhance the readability of our project history, simplify automated changelog generation, and streamline the release process. We primarily follow the Conventional Commit and Angular’s commit guidelines.

Commit Message Pattern¶

<type>(<optional scope>): <description>

Examples:

build(dependencies): bump the prod group with 9 updates.
doc: Add doc for commit convention.
chore: remove deprecated key in ruff config.

Type: Describes the nature of the change:

Type	Description
`build`	Changes that affect the build system or dependencies.
`chore`	Routine tasks or changes outside the src/runtime code.
`ci`	Changes related to continuous integration.
`doc`	Documentation changes.
`feat`	New features.
`fix`	Bug fixes.
`perf`	Performance improvements.
`refactor`	Code restructuring without changing behavior.
`revert`	Revert a previous commit.
`style`	Code formatting changes.
`test`	Add or update tests.

Scope [Optional]: Represents the part of the project impacted by the change. Examples include logging, settings, and cli.

Breaking Change¶

A “breaking change” refers to any modification that disrupts the existing functionality in a way that may affect users. It can be denoted using an exclamation mark (!) before the colon, like refactor!: Stuff.

Commit in Development Branches¶

While the commit convention seems strict, we aim for flexibility during the development phase. By adhering to the Repository Settings, all changes should be introduced via pull/merge requests. Using the squash merge strategy, the emphasis is primarily on the title of pull/merge requests. In this way, individual commit within development branches does not need to strictly adhere to the commit convention.

Note

A CI/CD pipeline checks the titles of pull/merge requests against the following regex pattern:

^(build|chore|ci|doc|feat|fix|perf|refactor|revert|style|test)(\(\w+\))?!?:\s.*