forked from trinitrix/core
Docs: update the commit message format to a modified version of the AngularJS commit message style
This commit is contained in:
parent
9c9da44341
commit
80f8c1709f
GPG Key ID:
2B4F402172791BAF
|
|
@ -1,29 +1,111 @@
|
||||||
# Commit message style
|
# Commit message style
|
||||||
|
*This specification is heavily inspired by the [AngularJS commit message format][https://github.com/angular/angular/blob/main/CONTRIBUTING.md#-commit-message-format].*
|
||||||
|
|
||||||
Commit messages have to align with the following style:
|
We have very precise rules over how our Git commit messages must be formatted.
|
||||||
|
This format leads to **easier to read commit history**.
|
||||||
|
|
||||||
`<type> (<space>): <change>`
|
Each commit message consists of a **header**, a **body** (optional), and a **footer** (optional).
|
||||||
|
|
||||||
Pull requests that don't align with this style probably won't be accepted.
|
|
||||||
|
|
||||||
## type
|
```
|
||||||
The type of change to be committed.
|
<header>
|
||||||
|
<BLANK LINE>
|
||||||
|
<body>
|
||||||
|
<BLANK LINE>
|
||||||
|
<footer>
|
||||||
|
```
|
||||||
|
|
||||||
Possible values:
|
The `header` is mandatory and must conform to the _Commit Message Header format_ (described below).
|
||||||
- __feature__ - When you added a new feature or functionality.
|
|
||||||
- __fix__ - When you fixed a bug or stuff like that.
|
|
||||||
- __docs__ - When you wrote documentation or changed the readme. The space field is optional here.
|
|
||||||
- __refactor__ - When you restructured the codebase / parts of it. The space field is optional here.
|
|
||||||
|
|
||||||
If your commit has multiple types, think about splitting it into multiple commits.
|
The `body` is mandatory for all commits that are not 100% self explainatory.
|
||||||
This helps others (and you) to understand changes in retrospect.
|
When the body is present it must be at least 20 characters long and must conform to the _Commit Message Body format_.
|
||||||
|
|
||||||
## space
|
The `footer` is optional. The _Commit Message Footer format_ (described below) describes what the footer is used for and the structure it must have.
|
||||||
The space that is affected by the commit.
|
|
||||||
|
|
||||||
## change
|
|
||||||
What you've changed. / The actual commit message.
|
|
||||||
|
|
||||||
# Examples
|
## Commit Message Header
|
||||||
- `feature (AHCI): implemented port initialization`
|
|
||||||
- `fix (processes): changed process spawning to copy the null terminator at the end of the name`
|
```
|
||||||
|
<type>(<scope>): <short summary>
|
||||||
|
│ │ │
|
||||||
|
│ │ └─⫸ Summary in present tense. Not capitalized. No period at the end.
|
||||||
|
│ │
|
||||||
|
│ └─⫸ Commit Scope: The name of the affected module.
|
||||||
|
│
|
||||||
|
└─⫸ Commit Type: Build|Docs|Feat|Fix|Perf|Refactor|Test|Merge
|
||||||
|
```
|
||||||
|
|
||||||
|
The `<type>` and `<summary>` fields are mandatory, the `(<scope>)` field is optional.
|
||||||
|
|
||||||
|
|
||||||
|
### type
|
||||||
|
|
||||||
|
Must be one of the following:
|
||||||
|
|
||||||
|
* **Build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
|
||||||
|
* **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
|
||||||
|
* **Merge**: A merging commit
|
||||||
|
|
||||||
|
### Scope
|
||||||
|
The scope should be the name of the module affected (as perceived by the person reading the changelog generated from commit messages).
|
||||||
|
|
||||||
|
Specify submodules if needed!
|
||||||
|
|
||||||
|
Example scopes:
|
||||||
|
|
||||||
|
* `app::events`
|
||||||
|
* `ui`
|
||||||
|
|
||||||
|
When a commit affects the whole tree, use `treewide`.
|
||||||
|
|
||||||
|
### Summary
|
||||||
|
|
||||||
|
Use the summary field to provide 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
|
||||||
|
|
||||||
|
|
||||||
|
## Commit Message Body
|
||||||
|
|
||||||
|
Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".
|
||||||
|
|
||||||
|
Explain the motivation for the change in the commit message body. This commit message should explain _why_ you are making the change.
|
||||||
|
You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.
|
||||||
|
|
||||||
|
This is not needed, if the summary is 100% self-explainatory.
|
||||||
|
|
||||||
|
## Commit Message Footer
|
||||||
|
|
||||||
|
The footer can contain information about breaking changes and deprecations and is also the place to reference issues and other PRs that this commit closes or is related to.
|
||||||
|
For example:
|
||||||
|
|
||||||
|
```
|
||||||
|
BREAKING CHANGE: <breaking change summary>
|
||||||
|
<BLANK LINE>
|
||||||
|
<breaking change description + migration instructions>
|
||||||
|
<BLANK LINE>
|
||||||
|
<BLANK LINE>
|
||||||
|
Fixes #<issue number>
|
||||||
|
```
|
||||||
|
|
||||||
|
or
|
||||||
|
|
||||||
|
```
|
||||||
|
DEPRECATED: <what is deprecated>
|
||||||
|
<BLANK LINE>
|
||||||
|
<deprecation description + recommended update path>
|
||||||
|
<BLANK LINE>
|
||||||
|
<BLANK LINE>
|
||||||
|
Closes #<pr number>
|
||||||
|
```
|
||||||
|
|
||||||
|
Breaking Change section should start with the phrase "BREAKING CHANGE: " followed by a summary of the breaking change, a blank line, and a detailed description of the breaking change that also includes migration instructions.
|
||||||
|
|
||||||
|
Similarly, a Deprecation section should start with "DEPRECATED: " followed by a short description of what is deprecated, a blank line, and a detailed description of the deprecation that also mentions the recommended update path.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue