📋 Commit Guidelines#

This section is meant for maintainers. Contributors do not need to worry about commit messages as PRs are squash-merged before being integrated into the project.

✍️ Commit Format#

We follow Conventional Commits to standardize commit messages, making it easier to understand the purpose of each change. Commit messages should include an emoji to indicate the type of change and follow the format below:

<type>[(<scope>)]: <message>

For breaking changes, add a ! after the type or scope.

🗂️ Commit Types#

✨ feat

Adds a new feature or significant functionality

🐛 fix

Corrects a bug or malfunction

⚡️ perf

Optimizes code to improve performance

♻️ refactor

Restructures existing code without changing its behavior

🎨 style

Updates code style without affecting behavior (e.g., formatting, spacing)

📝 docs

Changes or improves project documentation

🧪 test

Adds new tests or updates existing ones

🔨 build

Updates to scripts responsible for building project parts

⚙️ ci

Changes to continuous integration workflows or scripts

🛠️ chore

Routine tasks like version bumps, metadata updates, or asset maintenance

🎯 Using Scopes#

Commit messages can include a scope to specify which part of the project is affected. Example:

📝 docs(bs.block): update get_block output

⚠️ Breaking Changes#

If a change introduces a breaking change, add a ! after the type or scope. Example:

✨ feat(bs.block)!: add a new macro argument to the replace_type function

This helps ensure that users are aware of any changes that might affect compatibility.