Commit convention

Committing

1. Before committing, a diff must be made for all files to be committed, and the diff must be reviewed. Specific environment files or other irrelevant information must not be committed.
2. Each task must be in its own branch. For a GitHub issue like "Add new component #8", the branch would be feat/8-add-new-component. See Branch name below.
3. Commit messages must follow the commit message format recommended by semantic-release, based on the Angular conventions. Releases are produced from these messages, so the format is not cosmetic, an incorrectly typed commit produces the wrong version, or no release at all.

Each commit message consists of a header, a body and a footer:

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The <type> and <summary> fields are mandatory. The (<scope>) field is optional.

Commit message header

<type>(<scope>): <short summary> #<issue number>
  │       │             │              │
  │       │             │              └─⫸ Issue number that has been created in GitHub
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit scope: [component name]
  │
  └─⫸ Commit type: feat|fix|chore|docs|build|ci|perf|refactor|revert|test

The issue number belongs in the header, at the end of the summary.

Branch name

Branch names consist of a branch type, the issue number and a short description:

<type>/<issue number>-<short description>

The issue number comes first, directly after the type. Use lowercase and separate words with hyphens.

GitHub issue	Branch name
Add new component #8	feat/8-add-new-component
Mobile tabs alignment #10	fix/10-mobile-tabs-alignment
Folder structure improvement #166	chore/166-folder-structure-improvement

Branch types

The branch type uses the same vocabulary as the commit type. In practice these four cover nearly everything:

• feat: new features
• fix: bug fixes for existing components and code
• chore: maintenance work that is not a feature or a fix
• docs: documentation only changes

Branches created by automation (for example dependabot/...) do not follow this convention and are not expected to.

Type

Must be one of the following:

Type	Meaning
feat	A new feature
fix	A bug fix
chore	Maintenance work with no effect on the published library
docs	Documentation only changes
build	Changes that affect the build system or external dependencies
ci	Changes to CI configuration files and scripts
perf	A code change that improves performance
refactor	A code change that neither fixes a bug nor adds a feature
revert	Reverts a previous commit
test	Adding missing tests or correcting existing tests

The first four cover almost all work in practice; the rest are valid but rarely used.

Only feat, fix and commits marked as breaking changes trigger a release. The remaining types are recorded but produce no new version.

Scope

The scope should be the name of the component affected, as perceived by the person reading the changelog generated from commit messages.

Summary

Use the summary field to provide a succinct description of the change:

• use the imperative, present tense: "change" not "changed" nor "changes"
• don't capitalize the first letter
• no dot (.) at the end

Commit message body

Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".

Explain the motivation for the change in the commit message body. The body should explain why you are making the change. You can include a comparison of the previous behaviour with the new behaviour in order to illustrate the impact of the change.

Commit message footer

The footer carries breaking changes and deprecations, and can reference other issues or PRs that the commit closes or relates to. For example:

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>

or

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>

A breaking change section must start with the phrase BREAKING CHANGE: followed by a summary of the breaking change, a blank line, and a detailed description that also includes migration instructions.

Similarly, a deprecation section must start with DEPRECATED: followed by a short description of what is deprecated, a blank line, and a detailed description that also mentions the recommended update path.

Examples

Commit message	Release type
fix(button): stop icon overflowing on narrow viewports #123	Patch release
feat(button): add 'loading' state #321	Minor release
feat(table): remove deprecated 'sortable' prop #333 BREAKING CHANGE: The 'sortable' prop has been removed. Use 'sortBy' instead. See the migration guide.	Major release (the BREAKING CHANGE: token must be in the footer)
chore(deps): bump eslint to 9.0.0 #444	No release

Task references

Every commit must reference a task. If there is a need to do something for which no task exists, a task must be created first.

The exception is commits produced by automation, such as chore(release): commits created by semantic-release, and dependency updates raised by dependabot. These have no issue to reference.