Consistent commits using Commitlint
Tags: webdev, beginners, git
Published: 2019-04-30 17:25:31

---
title: Consistent commits using Commitlint
published: true
description: Chances are you lint your code but did you know you can also lint your commits? Linting your project's Git history can be beneficial and here are the reasons I think so.
tags: webdev,beginners,git,
---

The hardest part of version control is representing the history of your project in a way that is meaningful and easy to digest for future readers.

Authoring commit messages is as much an art as it is a science. The thought and time that goes into ensuring code quality and standards are upheld should also be put into version control standards. You should be able to read back through the commit log and have a good idea of what has changed over time.

> If you cannot derive any meaning from your version control log then the history itself is meaningless.

When working on JavaScript/TypeScript code you often have a linter working alongside you to nudge you in the right direction. Following linting rules doesn't in any way ensure you're writing good quality, readable, bug-free code but it does definitely help you think about these things and nudge you in the right direction as you're working away.

What if you could employ the same concept of linting code but for git history?

The good news is, you can. Introducing `commitlint`, a simple way to enforce some standards across your VCS history.

But wait, what does this actually look like? What is an example of a commit that would pass the recommended ruleset?

One of the core concepts behind `commitlint` is adding "types" to your commmit messages. Your next question is probably, what does that look like?

```bash
docs: add contributing.md file
test: ensure hamburger menu is hidden on mobile
style: make Header component yellow by default
```

In the above cases, `docs`, `test` and `style` are the "types". They're present to give you a little bit more information about what is contained in the PR but  in a consistent way.

> If you want to see a list of all of the available "types" then check out the [`commitlint`](https://wwww.github.com/conventional-changelog/commitlint) Github page.

Some other niceties you can enforce using `commitlint` are things like whether the subject can be empty, whether it should have a full stop at the end of the line, what case the subject should be in, etc.

It is worth mentioning that, just like code linting, commit linting alone isn't a silver bullet. It is not the only thing you need to give you and your team nice, readable, history. You could still have plenty of commits that follow the standards perfectly and look like this:

```bash
feat: add big feature
style: improve styling
docs: explain more stuff
```

However, like we mentioned earlier - having a linter is a great way to nudge yourself (and your colleagues) in the right direction and invoke more thought about how we should write our project history.

So far I've worked with `commitlint` in some personal projects and a couple of OSS projects and I've really enjoyed it. I would recommend checking it out if you're interested in adding some consistency to your history.

Thanks for reading! If you have any questions about anything I've spoken about in this article then feel free to tweet me [@LukeHGlazebrook](https://www.twitter.com/LukeHGlazebrook)