Commit Message guidelines
I most of our projects, we follow the Conventional Commits specification for both clarity and automation purposes.
This document is a basic summary of the specification and how we use it, but you cna find more details on the Conventional Commits specification website.
Usage
The Conventional Commits specification defines standards for full commit messages with complete descriptions, issue references and other details. But for common usage in our projects, since details are usually documented on Issues or in the documentation of our projects, we can just focus on the summaries. Because of this usage, please refer to the Conventional Commits specification for detailed commit message conventions.
As a general rule, a commit message can take two forms:
type: short description
OR
type(scope): short description
Types
Based on the Angular team guidelines, the keyword can be one of the following:
fix: a bug fix or a resolved issuedocs: a change that occurs only in the documentationfeat: a new featurerefactor: a change that neither fixes a bug nor adds a featureci: A change to the CI configuration (eg. GitHub Actions)test: Adding missing tests or correcting existing testschore: A change with no impact for the users (eg. add version tag, deploy a Release, ...)
There's also some automatic behaviors related to the use of some of these keywords:
fix: implies a PATCH in Semantic Versioningfeat: implies a MINOR in Semantic Versioning- Adding
BREAKING CHANGEin the footer or a!after the type/scope: represents a breaking change and implies a MAJOR in Semantic Versioning (eg:fix!: removed v1 API calls)
Scopes
A scope is an optional part. It's a noun or an abbreviation for the subject of a change. Projects may have a shortlist of allowed scopes, but there's no common rules.
Here are some common examples:
lang: related to translationscore: related to the core systemscommon: related to utilities- ...
We recommend to not specify a scope if you're not sure of the one to use, as it is an optional part.