Conventional Commits is a compact, well-organized way of making commit messages. It provides a set of principles for adding human and computer-readable meaning to commits. Its principal objective is to enable the development of automated tools based on commit messages.
In this regard, it adds some distinctive items in the commit messages where the type of the commit stands out as one. The next table gives an overview of common types of commits that are described in the specification:
Structure:
<type>: <subject-description>
Example:
$git commit -m "feat: added new nav bar on template"
In addition,
A convention that sets the subject for a commit message thusly:
Following this structure, a commit that adds, for example, a new endpoint to an API to allow the creation of coupons, should have a subject that looks like this:
Structure:
<type>(optional scope): <subject-description>
A commit that adds a new endpoint to an API to allow the creation of coupons, for instance, should have a subject that looks like this:
Example:
$git commit -m "feat(api): Add support to create coupons"
Besides, we can append BREAKING CHANGE: in the footer of the commit to indicate that it introduces breaking changes. On the other hand, after the commit type, we can insert ! to highlight the breaking changes.
Example:
"chore!: Update PHP version to min 8.2
also you can add 'BREAKING CHANGE' footer for extra description to the commit.
"chore!: downgraded PHP version to 8.1 from 8.2
BREAKING CHANGE: use packages that supports php 8.1"
Top comments (2)
nice one ! sometimes I use additional emoji to understand more easily
Like 🆙 for update , ✏️ for creating. its fun :P
Before using Conventional Commits, I used to commit with the comment "update" only 🤦♂️. But once I started using this format, my commits became much more understandable over time. 🔥