Git commit format
Describe the format about how to write your commit
Message format
The message format follow 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 below format structure:
|
|
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:
fetch
endpoint has been removed, should replace it
withget
endpoint.
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.