Conventional commits

Dmytro Tus

Full Stack Web developer

Conventional Commits is a specification for writing standardized commit messages in version control systems like Git. It provides a structured format that helps developers understand the history of changes, automate versioning (like with semantic versioning), and improve collaboration.

I decided to start using that in my workflow and I will leave some the most important rules that I am using.

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.

Examples:

commit 1:
fix: Resolved wrong product calculation

commit 2:
feat: Added new cart items logic

commit 3:
feat!: Added new product listing logic // ! means that there are breaking changes

commit 4:
style: Added new code styling

commit 5:
refactor: Listing logic

In the Conventional Commits system, the commit type chore refers to routine tasks or maintenance that don’t change application behavior or logic and aren’t directly related to features, fixes, or tests.

Examples:
chore: update npm dependencies
chore: rename configuration files
chore: clean up build artifacts
chore: update .gitignore
chore: configure ESLint rules