-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: update SEMANTIC_COMMITS content
- Loading branch information
1 parent
4abca38
commit 2c9e3ac
Showing
4 changed files
with
94 additions
and
26 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,34 +1,102 @@ | ||
# Semantic Commit Messages | ||
## Git Commit Message Convention | ||
|
||
See how a minor change to your commit message style can make you a better programmer. | ||
> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular). | ||
Format: `<type>(<scope>): <subject>` | ||
#### TL;DR: | ||
|
||
`<scope>` is optional | ||
Messages must match the following regex: | ||
|
||
## Example | ||
```js | ||
;/^(revert: )?(feat|fix|docs|style|refactor|test|ci|chore)(\(.+\))?: .{1,120}/ | ||
``` | ||
#### Types | ||
- `feat` - new functionality. | ||
- `fix` - patching a bug. | ||
- `docs` - documentation and comments. | ||
- `style` - style changes only (not necessarily in css). | ||
- `refactor` - reworking internals without impacting project interface. | ||
- `test` - tests and demo. | ||
- `ci` - deploy and continuous integration. | ||
- `chore` - no significant code changes: code formatting, version changes, tool updates, minor refactorings. | ||
#### Examples | ||
Appears under "Features" header, `compiler` subheader: | ||
``` | ||
feat: add hat wobble | ||
^--^ ^------------^ | ||
| | | ||
| +-> Summary in present tense. | ||
| | ||
+-------> Type: chore, docs, feat, fix, refactor, style, or test. | ||
feat(compiler): add 'comments' option | ||
``` | ||
|
||
Appears under "Bug Fixes" header, `model` subheader, with a link to issue #28: | ||
|
||
``` | ||
fix(model): handle events on blur | ||
close #28 | ||
``` | ||
|
||
More Examples: | ||
Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation: | ||
|
||
``` | ||
feat(core): improve vdom diffing by removing 'foo' option | ||
BREAKING CHANGE: The 'foo' option has been removed. | ||
``` | ||
|
||
The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header. | ||
|
||
``` | ||
revert: feat(compiler): add 'comments' option | ||
This reverts commit 667ecc1654a317a13331b17617d973392f415f02. | ||
``` | ||
|
||
### Full Message Format | ||
|
||
A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**: | ||
|
||
``` | ||
<type>(<scope>): <subject> | ||
<BLANK LINE> | ||
<body> | ||
<BLANK LINE> | ||
<footer> | ||
``` | ||
|
||
The **header** is mandatory and the **scope** of the header is 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. | ||
|
||
### Type | ||
|
||
If the prefix is `feat` or `fix` it will appear in the changelog. However if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog. | ||
|
||
Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks. | ||
|
||
### Scope | ||
|
||
The scope could be anything specifying place of the commit change. For example `core`, `compiler`, `ssr`, `model`, `transition` etc... | ||
|
||
### Subject | ||
|
||
The subject contains succinct description of the change: | ||
|
||
- use the imperative, present tense: "change" not "changed" nor "changes" | ||
- don't capitalize first letter | ||
- no period (.) at the end | ||
|
||
### Body | ||
|
||
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". | ||
The body should include the motivation for the change and contrast this with previous behavior. | ||
|
||
- `feat`: (new feature for the user, not a new feature for build script) | ||
- `fix`: (bug fix for the user, not a fix to a build script) | ||
- `docs`: (changes to the documentation) | ||
- `style`: (formatting, missing semi colons, etc; no production code change) | ||
- `refactor`: (refactoring production code, eg. renaming a variable) | ||
- `test`: (adding missing tests, refactoring tests; no production code change) | ||
- `chore`: (updating grunt tasks etc; no production code change) | ||
### Footer | ||
|
||
References: | ||
The footer should contain any information about **Breaking Changes** and is also the place to | ||
reference GitHub issues that this commit **Closes**. | ||
|
||
- https://www.conventionalcommits.org/ | ||
- https://seesparkbox.com/foundry/semantic_commit_messages | ||
- http://karma-runner.github.io/1.0/dev/git-commit-msg.html | ||
**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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters