Message format
The message format follows the 50/72 rule:
The characters of first line of the commit can not longer than 50, and the characters of other lines can not longer than 72.
You can see the below format structure:
<type>(<scope>): <subject>
<body>
<footer>
Message subject
Just like above-mentioned, the first line can not longer than 50 characters, and it consists of type, scope (optional) and subject message.
Allowed type values
| Value | Description |
|---|---|
| feat | Has new feature for end-user |
| fix | Has bug fix for end-user |
| docs | Change to the documentation, include the inside manual and outside manual. |
| style | Formatting, missing semicolons, etc., no production code change. |
| refactor | Refactoring production code, e.g., renaming a variable. |
| test | Adding missing tests, refactoring test, no production code change. |
| chore | Updating other tasks without production code change. e.g., add a new build script. |
What’s the scope
The scope is used to describe: your change will impact which part of the system.
The possible values are: init, config, proxy, etc.
Message body
Uses the imperative, present tense: “change” not “changed” nor “changes” includes motivation for the change and contrasts with previous behavior.
Message footer
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:
fetchendpoint has been removed, should replace it
withgetendpoint.
Example
refactor(dns): rename existing domain name.
rename domain a to b, because we no longer need to use the domain a
and currently we got domain b for our services.
BREAKING CHANGE: could impact all services which use the domain name to
connect to the existing service, should update their configuration to
avoid connection failure.