In the repository we use and enforce the commit message conventions. The conventions are verified using commitlint with Angular config.
The reasons for these conventions: #
- automatic generating of the changelog
- simple navigation through git history (e.g. ignoring style changes)
Format of the commit message: #
Example commit message: #
fix(middleware): ensure Range headers adhere more closely to RFC 2616
Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.
Message subject (first line) #
The first line cannot be longer than 72 characters and should be followed by a blank line. The type and scope should always be lowercase as shown below.
<type> values: #
- feat for a new feature for the user, not a new feature for build script. Such commit will trigger a release bumping a MINOR version.
- fix for a bug fix for the user, not a fix to a build script. Such commit will trigger a release bumping a PATCH version.
- perf for performance improvements. Such commit will trigger a release bumping a PATCH version.
- docs for changes to the documentation.
- style for formatting changes, missing semicolons, etc.
- refactor for refactoring production code, e.g. renaming a variable.
- test for adding missing tests, refactoring tests; no production code change.
- build for updating build configuration, development tools or other changes irrelevant to the user.
<scope> values: #
<scope> can be empty (e.g. if the change is a global or difficult
to assign to a single component), in which case the parentheses are
omitted. In smaller projects such as Karma plugins, the
<scope> is empty.
Message body #
Just as in the
<subject>, use the imperative, present tense: "change" not "changed" nor "changes". Message body should include motivation for the change and contrasts with previous behavior.
Referencing issues #
Closed issues should be listed on a separate line in the footer prefixed with "Closes" keyword like this:
or in the case of multiple issues:
Breaking changes #
All breaking changes have to be mentioned in footer with the
description of the change, justification and migration notes.
`port-runner` command line option has changed to `runner-port`, so that it is
consistent with the configuration file syntax.
To migrate your project, change all the commands, where you use `--port-runner`
Any commit with the breaking change section will trigger a MAJOR release and appear on the changelog independently of the commit type.
This document is based on Angular Commit Message Format. See the commit history for examples of properly-formatted commit messages.