Write Better Commits

2 min readMar 26, 2022

Good commits are important for any project whether it’s a side project or long term projects. It helps to keep track of the commits and see easily what changes are being done in each commit. It also helps a lot in collaboration with other developers. Writing consistent, meaningful commit messages are hard, that’s why in this guide we’ll learn a way to improve commits messages with Conventional Commits.

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

Why Use Conventional Commits?

Automatically generating CHANGELOGs
Automatically determining a semantic version bump (based on the types of commits landed)
Communicating the nature of changes to teammates, the public, and other stakeholders
Triggering build and publish processes
Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history

Types of conventions

feat: Must be used when a commit adds a new feature to your application or library.
fix: MUST be used when a commit represents a bug fix for your application.
style: Feature and updates related to styling
refactor: Refactoring a specific section of the codebase focused on readability, style and/or performance.
test: Everything related to testing
docs: Everything related to documentation
chore: Regular code maintenance.[You can also use emojis to represent commit types]
HOTFIX: If any urgent fixes required.

Below you can see the structure that Conventional Commits follows.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

<type>

The type is intended to describe the category of your change. The most common types are: build, chore, ci, docs, feat, fix, perf, refactor, revert, style and test.

[optional scope]

The second, optional part is the so called scope. The scope Describes the module affected by your change.

<description>

The description is where describe the alterations made by your commit.
The easiest way to get an idea of what it looks like is by seeing some examples.

Here are some minimal commit messages satisfying the rules.

$ git commit -m 'chore: add express'
$ git commit -m 'feat(lang): add polish'
$ git commit -m 'fix: prevent racing of requests'
$ git commit -m 'docs: correct spelling of CHANGELOG'

I highly recommend you give it a try and learn more about it on their official website.