Commit Messages

Guideline and standard for commit messages

The format of the commit messages was adapted from the Angular Commit Message Format.

Using a commit message stardard makes all commits readable and understandable to all people adhering to the standard, the same way a communication protocol works.

Commit Message Format

Each commit message consists of a header, a body, and a footer.

<header>
/** BLANK LINE **/
<body>
/** BLANK LINE **/
<footer>

<header>

Mandatory field

<type>: <short summary>
  │                     │
  │                     └─⫸  Summary in present tense. 
  │                           Not capitalized. 
  │                           No period at the end.       
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

<type>

  • build: Changes that affect the build system

  • ci: Changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)

  • docs: Documentation only changes

  • feat: A new feature

  • fix: A bug fix

  • perf: A code change that improves performance

  • refactor: A code change that neither fixes a bug nor adds a feature

  • test: Adding missing tests or correcting existing tests

For a more complete explanation of type take a look here.

<summary>

Use the summary field to provide a brief description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"

  • don't capitilize first letters

  • do not ( . ) at the end

<body>

Mandatory field

  • Use the imperative, present tesnse: "fix" not "fixed" nor "fixes"

  • Explain the motivation of the commit

  • Why you are making the change

  • Try comparing the previous behaviours to the new behaviour in order to illustrate the impact of the change

<footer>

Information about:

  • Breaking changes

  • Reference GitHub issue

  • Reference Jira Ticket

  • References to problems that this commit closes

Example 1

Example 2

Last updated