Type | Description | Example |
---|---|---|
|
Features |
A new feature |
|
Bug Fixes |
A bug fix |
|
Documentation |
Documentation only changes |
|
Styles |
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
|
Code Refactoring |
A code change that neither fixes a bug nor adds a feature |
|
Performance Improvements |
A code change that improves performance |
|
Tests |
Adding missing tests or correcting existing tests |
|
Builds |
Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
|
Continuous Integrations |
Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
|
Chores |
Other changes that don’t modify src or test files |
|
Reverts |
Reverts a previous commit |
<type>([optional scope]): <description>
[optional admonition] [optional body]
[optional footer]
Note
|
1. Use + for addition 2. Use - for removal 3. Use ~ for change 4. Use ! to draw attention (e.g. breaking change) |
fix(etl)!: prevent racing of requests
+ Introduce a request id and a reference to latest request.
- Remove timeouts which were used to mitigate the racing issue but are obsolete now.
~ Modify the request handling logic to prevent racing.
Refs: #123
BREAKING CHANGE: Use JavaScript features not available in Node 6.
Note
|
Refs are references to issues or pull requests. |
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
-
Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by a colon and a space.
-
The type feat MUST be used when a commit adds a new feature to your application or library.
-
The type fix MUST be used when a commit represents a bug fix for your application.
-
An optional scope MAY be provided after a type. A scope is a phrase describing a section of the codebase enclosed in parenthesis, e.g., fix(parser):
-
A description MUST immediately follow the type/scope prefix. The description is a short description of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
-
A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
-
A footer MAY be provided one blank line after the body. The footer SHOULD contain additional issue references about the code changes (such as the issues it fixes, e.g., Fixes #13).
-
Breaking changes MUST be indicated in the footer AND by appending a ! after the type/scope. A BREAKING CHANGE introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.
-
A description MUST be provided after the BREAKING CHANGE:, describing what has changed about the API, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
-
The footer MUST only contain BREAKING CHANGE, external links, issue references, and other meta-information.
-
Types other than feat and fix MAY be used in your commit messages.