Commitlint is a powerful tool designed to enforce consistent and meaningful commit message conventions in software development projects. By integrating commitlint into your workflow, you can ensure that your commit messages adhere to a predefined standard, improving the quality and maintainability of your codebase. Here's why commitlint is valuable:

1. Enforces Consistent Commit Messages
   • Commitlint helps enforce a consistent structure for commit messages, such as adhering to the Conventional Commits specification. Consistent commit messages make it easier to:
     • Understand the purpose of each commit.
     • Identify the type of changes (e.g., features, bug fixes, documentation updates).
     • Generate changelogs automatically.
2. Improves Collaboration
   • In team environments, commitlint ensures that all developers follow the same commit message conventions. This consistency:
     • Reduces confusion when reviewing commit histories.
     • Makes it easier for team members to understand the context of changes.
3. Enhances Automation
   • Commitlint integrates seamlessly with CI/CD pipelines and tools like semantic-release. By enforcing commit message standards, it enables:
     • Automated versioning based on commit types (e.g., feat for a minor version bump, fix for a patch).
     • Automatic changelog generation, saving time and reducing manual effort.

This sections highlights how to write commit message. See the Commitlin Tutorial to learn how to use the VS Code extension.

Make sure commit message are short and to the point. Several examples are highlighted in the section below.

• feat: add email notifications on new direct messages
  

• feat(shopping cart): add the amazing button
  

• feat!: remove ticket list endpoint
  refers to JIRA-1337
  BREAKING CHANGES: ticket enpoints no longer supports list all entites.
  

• fix(shopping-cart): prevent order an empty shopping cart
  

• fix(api): fix wrong calculation of request body checksum
  

• fix: add missing parameter to service call
  The error occurred because of <reasons>.
  

• perf: decrease memory footprint for determine uniqe visitors by using HyperLogLog
  

• build: update dependencies
  

• build(release): bump version to 1.0.0
  

• refactor: implement fibonacci number calculation as recursion
  

• style: remove empty line
  

• API relevant changes
  • feat Commits, that adds or remove a new feature
  • fix Commits, that fixes a bug
• refactor Commits, that rewrite/restructure your code, however does not change any API behaviour
  • perf Commits are special refactor commits, that improve performance
• style Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
• test Commits, that add missing tests or correcting existing tests
• docs Commits, that affect documentation only
• build Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
• ops Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
• chore Miscellaneous commits e.g. modifying .gitignore

The scope provides additional contextual information.

• Is an optional part of the format
• Allowed Scopes depends on the specific project
• Don't use issue identifiers as scopes

Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint

• Is an optional part of the format

The description contains a concise description of the change.

• Is a mandatory part of the format
• Use the imperative, present tense: "change" not "changed" nor "changes"
  • Think of This commit will... or This commit should...
• Don't capitalize the first letter
• No dot (.) at the end

The body should include the motivation for the change and contrast this with previous behavior.

• Is an optional part of the format
• Use the imperative, present tense: "change" not "changed" nor "changes"
• This is the place to mention issue identifiers and their relations

The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to.

• Is an optional part of the format
• optionally reference an issue by its id.
• Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.

• https://www.conventionalcommits.org/
• https://commitlint.js.org/