# Commitlint with Husky

# Introduction

Commitlint is a tool that enforces consistent and meaningful commit message conventions in your Git repositories. It ensures that commit messages follow a predefined convention, such as the commitlint-config-conventional (based on the Angular convention).

Commitlint, in conjunction with Husky, automates the process of commit message validation. Every commit message is automatically linted before the commit is executed

  • Husky: A "commit-msg" hook is established using Husky, triggering commitlint's checks before every commit.

  • commitlint: commitlint checks if your commit messages meet the conventional commit format.

# Commit Message Format

Commit messages typically follow this pattern:

type(scope?): subject  #scope is optional; multiple scopes are supported (current delimiter options: "/", "\" and ",")
body?  #body is optional
footer?  #footer is optional

# Type

Type Description
build Changes that affect the build system or external dependencies
chore Routine maintenance and tasks, keeping the codebase clean and organized (example: updated dependecies)
ci Changes to our CI configuration files and scripts
docs Documentation only changes
feat A new feature
fix A bug fix
perf A code change that improves performance
revert Reversing previous commits to address errors or issues
refactor A code change that neither fixes a bug nor adds a feature
style Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
test Adding missing tests or correcting existing tests

# Scope

A scope provides additional context. For Example:

feat(parser): add ability to parse arrays

# Subject

The subject should offer a brief description of the change and adhere to these rules:

  • Use the imperative and present tense: "change," not "changed" or "changes"
  • Do not capitalize the first letter
  • Do not include a dot (.) at the end

# Body

In the same way as the subject, use the imperative and present tense, such as "change," not "changed" or "changes." The body should provide the reason for the change and compare it to the previous behavior.

# Footer

In the footer, provide information about any significant changes and mention GitHub issues closed by this commit.

For Breaking Changes, start with "BREAKING CHANGE:" followed by a space or two newlines, and then use the rest of the commit message to explain these alterations.

# Configuration

For further configuration options, refer to the commitlint configuration guide