Standards for Merge Requests#

For MRs submitted to this project, please use titles that adhere to the following standards, inspired by the Conventional Commit standard. This allows us to keep a clean history and auto-generate Changelogs and release notes(planned).

Note

This project uses squash merging for all merge requests. The final commit message for each merge is taken from the merge request (MR) title, not from individual commit messages. Therefore, the Conventional Commit standard described here applies only to MR titles.

Why Use Conventional Commits for MR Titles?#

  • Automated changelogs: MR titles are parsed to generate changelogs and release notes.

  • Consistent history: Makes it easy to understand the purpose of each merged change.

  • Tooling support: Many CI/CD tools and code review systems support this format.

MR Title Format#

Each MR title must follow this pattern:

type(scope)!: description

  • type: The kind of change (see allowed types below)

  • scope (optional): The part of the codebase affected, in parentheses

  • ! (optional): Indicates a breaking change

  • description: Short summary of the change

Allowed Types#

  • feat: A new feature

  • fix: A bug fix

  • chore: Routine task, build, or maintenance

  • docs: Documentation only changes

  • style: Formatting, missing semi colons, etc; no code change

  • refactor: Code change that neither fixes a bug nor adds a feature

  • perf: Performance improvement

  • test: Adding or correcting tests

  • ci: Adding or updating the pipelines

Examples#

  • feat(task manager): add task manager service and dashboard component

  • fix(client): handle empty columns in database query

  • docs: update README with setup instructions

  • refactor(core)!: remove deprecated method

Breaking Changes#

To indicate a breaking change, add ! after the type or scope:

  • feat!: drop support for Python 3.7

  • fix(core)!: change API response format

Tips for MR Authors#

  • Use the imperative mood in the description (e.g., “add”, not “added” or “adds”).

  • Keep the description concise and clear.

  • If your change is a breaking change, describe the impact in the MR body.

  • Individual commit messages do not need to follow this standard—only the MR title matters.

For more details, see Conventional Commits.