Git Commit Msg

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

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

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.

Fixes #2310

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.

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

Example <scope> values: #

  • init
  • runner
  • watcher
  • config
  • web-server
  • proxy
  • etc.

The <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:

Closes #234

or in the case of multiple issues:

Closes #123, #245, #992

Breaking changes #

All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.

BREAKING CHANGE:

`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`
to `--runner-port`.

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.