Commit guidelines

This documentation is based on Angular.js contributing guidelines

Commit message format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

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

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 80 characters. This allows the message to be easier to read on Github as well as in various git tools.

Type

The type of the commit is mandatory as it helps to the generation of the changelog automatically. Must be one of the following:

  • feat: A new feature or component. This type of commit is used for code that is being built.
  • fix: A bug fix, this type is used for fixes on components that have been already released.
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests
  • build: Changes to the build process or auxiliary tools and libraries such as documentation generation

Scope

The scope could be anything specifying place of the commit change.

Rules

  • Possible values:
    • Component CSS class name. ie: A-Link
    • core
    • If in the build, the section: parcel, scss, release, config, docs
  • 1 or 2 words camelCased
  • No blank spaces

Subject

The subject contains succinct description of the change. Make sure it provides enough information to tell the reader, what is the commit for.

Rules

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • no dot (.) at the end
  • Length < 60chars [This is not a strong guideline, however the idea of it is to tell you: Keep short your subject]

Tickets

The related JIRA ticket. Every commit message should have a ticket number to enable tooling to connect commits to tickets and vise versa.

Rules

  • Use the ticket number of the ticket you are doing the commit for, which is never the pull request number.
  • Multiple ticket numbers are written separated by comas

Body

Description of the commit. The body should include the motivation for the change and contrast this with previous behavior. Answers:

  • Why?: The body should include the motivation for the change
  • How?: High level contrast this with previous behavior.

Rules

  • use the imperative, present tense: "change" not "changed" nor "changes".
  • Length < 100 chars per line

The footer should contain any information about a BREAKING CHANGE. Answers: What side effects does this change have?

Rules

  • Must start with the words: 'BREAKING CHANGE'
  • Up to two bullet points. More than that mean that the commit does too much and should be split.
  • Length < 100 chars per line

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Special commits. Revert

Note: This should not happen, if it does, make sure you know what you are doing and to follow this guidelines. If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>, where the hash is the SHA of the commit being reverted.