Skip to main content

Commitlint

Rationale

Commitlint is the tool we use to standardize our commit messages and enforce compliance during CI/CD tests. By using Commitlint, we achieve well-structured commit messages that:

  1. Follow a convention.
  2. Are readable for humans and machines.

The main reasons why we chose it over other alternatives are:

  1. It allows us to have a standardized commit history, greatly improving documentation on what each commit does from a high level perspective while avoiding ending up with a messy commit history.
  2. It supports testing commit messages via CLI, allowing us to automate it as a CI job.
  3. As commit data is standardized, it allows us to run data analytics on our commit history and answer questions like What percentage of the commits in the last month were backend features?, How many developers worked on the front end of our application in the last month?, among many others.
  4. It is Open source.
  5. It is widely used by the community.
  6. It allows us to declare a syntax based on our own needs.
  7. It supports many rules that can be tuned based on our own needs.

Alternatives

  1. git-commit-msg-linter: It has a much smaller ruleset. It is not as widely used by the community.

Usage

We use Commitlint for:

  1. Linting commit messages in our repository.

Guidelines

  1. You can run ./m makes.lint-commit-msg for linting your last commit message.
  2. You can find commits syntax documentation here.
  3. You can find merge requests syntax documentation here.