When writing commit messages, it’s ideal to make them easy for another developer to read and understand exactly what’s in the commit. Oftentimes, though, we write commit messages quickly just to push a branch at the end of a workday, for instance (I know I’m guilty of this).

One team member brought the Conventional Commits format to our attention. I’ve enjoyed using it and seeing the results when reviewing pull requests.

To enforce this pattern, I recommend using this tool: conventional-changelog/commitlint: 📓 Lint commit messages.

Verbatim from the readme:

In general the pattern mostly looks like this:

type(scope?): subject  #scope is optional

Real world examples can look like this:

chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section

Common types:

  • build
  • ci
  • chore
  • docs
  • feat
  • fix
  • perf
  • refactor
  • revert
  • style
  • test

Want to edit your commit messages before you do a pull request? Squash your commits! Here are four nifty guides on how to do it:

A Beginner’s Guide to Squashing Commits with Git Rebase

How to squash multiple commits in git – Daniel Gitu – Medium

Git: Squash your latests commits into one - ariejan de vroom

Squash All Commits Related to a Single Issue into a Single Commit

In a nutshell, use git rebase the branch you’re on and pick, edit, or squash the commits interactively.


The conventional commit format is definitely worth trying for both team and personal projects.

Using a Code Style Guide to Enforce Team Best Practices