---
date: 2020-11-15
id: e57b1687-eeb8-4d10-b152-015a9d8dcec4
title: Commit guidelines
---
# Commit Message Format
<type>(<scope>)<!>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
# !
Append after `<type>(<scope>)` to show commit has a breaking change
(optional)
# Revert
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.
# Types
- **build**: Changes that affect the build system or external
dependencies (example scopes: gulp, broccoli, npm)
- **ci**: Changes to our CI configuration files and scripts (example
scopes: Travis, Circle, BrowserStack, 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
- **style**: Changes that do not affect the meaning of the code
(white-space, formatting, missing semi-colons, etc)
- **test**: Adding missing tests or correcting existing tests
# Subject
The subject contains a succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor
"changes"
- don't capitalize the first letter
- no dot (.) at the end
# Footer
The footer should contain any information about **Breaking Changes** and
is also the place to reference GitHub/Gitlab issues that this commit
**Closes**.
**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.