🔰 Organized Git commits with Commitlint

Intro

Unlock Commitlint's potential! Master structured Git commits for collaboration, simplified management. Explore benefits, setup, and elevate code quality.

Embracing conventions: building consistency in development

If you want to know the all course concepts, technologies and understand what kind of Node and npm versions you need, check the initial lesson - Course overview.

If you already read this article - jump into Gatsby5 | Tailwind | TypeScript | Cypress | jest and RTL template and check commits to understand the progress.

In previous lesson - 🌟 TailwindCSS dark mode configuration in Gatsby, we added support for dark mode. Now, it's time to add Commitlint and some conventions to our commits.

Imagine a big project that you joined yesterday. Almost 1000 commits. So, you would like to check the progress of the project from a time perspective and verify how dedicated features have been developed. Traversing all of these commits may be really time-consuming and if their messages are not clear enough - you will have tons of problems understanding the context of the provided change...

In another way, imagine a situation in which you made a problematic, buggy code and it has been pushed to the main branch. If your commit messages will look like in the below image, reverting these changes will be really hard.

That's why adding conventions for commits in your Git repository will make all of these activities much easier. You'll be able to understand the context, scope, and the reason why dedicated change has been added just by checking the commit name/message/body.

The most popular conventions are from Conventional commits specification. This guide describes how we should name our commit messages and provides skeleton for commit body. Here you have some examples:

Is it easier to read and understand? Definitely YES💥!

Feel free to check the full Conventional commits specification for more conventions.

Commitlint: key to meaningful Git commits

Verifying every commit manually will time consuming. So, I have good news for you. There is a plugin called Commitlint which does it for us. If the commit does not meet the conventions, during the commit stage in our IDE, we will get an error.

The same situation should occur on pipelines during the pull request, but this will be covered in the next lessons.

Quick guide to configure Commitlint with Husky

We've already configured Husky in 🌟 Adding Eslint with Prettier and Husky to project lesson. If you don't know how to achieve it, just read it. So, we'll skip this part.

First, we need to install packages as development dependency with following command: npm i --save-dev @commitlint/cli commitlint/config-conventional.

Now, it's time for the configuration file in which we'll specify some rules for Commitlint. Let's create the commitlint.config.js file in the root directory with following content.

The last part is adding commit-msg file under .husky directory.

The first line indicates the interpreter to use. The second one runs another script - husky.sh. The last line triggers Commitlint with edit mode.

The result

Our Commitlint should protect us from making ugly commits in following way:

To get current result jump into Gatsby5 | Tailwind | TypeScript | Cypress | jest and RTL template and check commits to understand the progress.

Conclusions and next steps

Now you understand the impact of having well and human-friendly commit messages. After this lesson, you should be able to use them and you have a policeman that protects you from making mistakes. Everything is automated via a simple @commitlint/config-conventional plugin and Husky library.

In the next 🌟 Integrating Zustand state management with Gatsby and React lesson, we'll cover Zustand library setup in Gatsby ecosystem.