# 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.

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

consistency commitlint conventional commit commit linting