Consistent commits using Commitlint

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?

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 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:

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