Conventional Commit

Conventional Commit Messages

Follow these conventions when creating commits.

Prerequisites

Before committing, ensure you're working on a feature branch, not the main branch.

# Check current branchgit branch --show-current

If you're on main or master, create a new branch first:

# Create and switch to a new branchgit checkout -b <type>/<short-description>

Branch naming should follow the pattern: <type>/<short-description> where type matches the commit type (e.g., feat/add-user-auth, fix/null-pointer-error, refactor/extract-validation).

Format

<type>(<scope>): <subject>
<body>
<footer>

The header is required. Scope is optional. All lines must stay under 100 characters.

Commit Types

Subject Line Rules

• Use imperative, present tense: "add feature" not "added feature"
• Do not capitalize the first letter
• No period at the end
• Maximum 70 characters

Body Guidelines

• Explain what and why, not how
• Use imperative mood and present tense
• Include motivation for the change
• Contrast with previous behavior when relevant

Conventional Commits

The commit contains the following structural elements, to communicate intent to the consumers of your library:

• fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in Semantic Versioning).
• feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
• BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
• types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.
• footers other than BREAKING CHANGE: <description> may be provided and follow a convention similar to git trailer format.

Examples

Simple fix

fix(api): handle null response in user endpoint
The user API could return null for deleted accounts, causing a crashin the dashboard. Add null check before accessing user properties.

Feature with scope

feat(alerts): add Slack thread replies for alert updates
When an alert is updated or resolved, post a reply to the originalSlack thread instead of creating a new message. This keeps relatednotifications grouped together.

Refactor

refactor: extract common validation logic to shared module
Move duplicate validation code from three endpoints into a sharedvalidator class. No behavior change.

Breaking change

feat(api)!: remove deprecated v1 endpoints
Remove all v1 API endpoints that were deprecated in version 23.1.Clients should migrate to v2 endpoints.
BREAKING CHANGE: v1 endpoints no longer available

Revert Format

revert: feat(api): add new endpoint
This reverts commit abc123def456.
Reason: Caused performance regression in production.

Principles

• Each commit should be a single, stable change
• Commits should be independently reviewable
• The repository should be in a working state after each commit

References

• Conventional Commits Specification