You are currently offline, so some features of this site may not work fully.

Your browser doesn’t support some of the latest CSS features used to build this site.

Read more about my usage of new CSS features.

By introducing a few pre-written Node packages into our workflow, this is how we established our commit message standards and enforced them across our entire front end team.

This post was originally written for the Code Lean blog.

I’m a big fan of conventions. No, not this kind of convention — what I mean is a set of guidelines and structured ways of working within a team.

Standardising commit message conventions

On the majority of projects I work on — personal, open source or commercial — I tend to stick to the commit message guidelines set out by the Angular project (occasionally omitting scope).


Following the instructions on Commitizen’s GitHub page, you install the package globally on your machine:

npm install commitizen -g
and initialise it in the repository of the project you want to enforce the conventions on:
commitizen init cz-conventional-changelog --save-dev --save-exact

Now make some changes, add your files and enter git cz instead of git commit and the Commitizen menu will come up:

An example of using Commitizen via the command-line tool

Git hooks

I’ve played with git hooks a fair bit before but one of the problems I had when collaborating was getting everyone to move the hooks that I’d written into their .git directory so they can be utilised correctly.

ghooks is an NPM package that helps with exactly this, allowing you to save commands in your package.json to be called in the appropriate place, like so:

"config": {
    "ghooks": {
    "commit-msg": "validate-commit-msg"

Install ghooks with npm install ghooks --save-dev and see the full list of git hooks available.

Now install a further Node package (by the author of Commitizen, no less) — validate-commit-msg with npm install validate-commit-msg --save-dev. This package implements commit message formats as a git hook, and by entering the default config, our commit messages will adhere to the Angular guidelines:

"validate-commit-msg": {
  "types": [
  "warnOnFail": false,
  "maxSubjectLength": 100,
  "subjectPattern": ".+",
  "subjectPatternErrorMsg": "subject does not match subject pattern!",
  "helpMessage": ""

Linking that packages task with the commit-msg hook and trying to commit with a message that doesn’t adhere to said guidelines throws an error, keeping all of our messages in a standard format.

An example of using validate-commit-message via the command-line tool

This might take some getting used to, but in my opinion the benefits of having standards within a team far outweigh the slight learning curve of sticking to conventions such as this.

Here’s a short demo of the process:

Use cases for commit message standards

Change logs

One of the reasons I like adhering to commit message standards is to automatically generate a CHANGELOG based on the types of commit messages. For example, all fix: messages can be pulled from the git history for a patch release, or all feat: messages for a minor.

Read more about Semantic Versioning for releases.

Git logs

Linked to this, having standardised commit messages makes searching and filtering git history via the command line easy and intuitive.

For example, git log --all --grep="fix" will find all fixes in the log which you could then filter down further with a date range.

Newer versions of git also support RegEx in git log searching: git log -G'feat' will find all features in the log. On the contrary, you could use this to filter out commits you don’t want to see, like style: for whitespace changes and chore: for chores that aren’t relevant to your log.

Read more at the git-log documentation.