Skip to content

Commit 86a384f

Browse files
mohammadllmohammadll
authored
Create CONTRIBUTING.md
1 parent 09141a7 commit 86a384f

File tree

1 file changed

+89
-0
lines changed

1 file changed

+89
-0
lines changed

‎CONTRIBUTING.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
### Commit message guidelines
2+
3+
#### Atomic commits
4+
5+
If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit), which means:
6+
7+
- a commit should contain exactly one self-contained functional change
8+
- a functional change should be contained in exactly one commit
9+
- a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature without documentation, etc...)
10+
11+
A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change.
12+
13+
#### Commit message format
14+
15+
Each commit message consists of a **header**, a **body** and a **footer**.
16+
The header has a special format that includes a **type**, a **scope** and a **subject**:
17+
18+
```commit
19+
<type>(<scope>): <subject>
20+
<BLANK LINE>
21+
<body>
22+
<BLANK LINE>
23+
<footer>
24+
```
25+
26+
The **header** is mandatory and the **scope** of the header is optional.
27+
28+
The **footer** can contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages).
29+
30+
#### Revert
31+
32+
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
33+
In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
34+
35+
#### Type
36+
37+
The type must be one of the following:
38+
39+
| Type | Description |
40+
| ------------ | ----------------------------------------------------------------------------------------------------------- |
41+
| **build** | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
42+
| **ci** | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
43+
| **docs** | Documentation only changes |
44+
| **feat** | A new feature |
45+
| **fix** | A bug fix |
46+
| **perf** | A code change that improves performance |
47+
| **refactor** | A code change that neither fixes a bug nor adds a feature |
48+
| **style** | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) |
49+
| **test** | Adding missing tests or correcting existing tests |
50+
51+
#### Subject
52+
53+
The subject contains succinct description of the change:
54+
55+
- use the imperative, present tense: "change" not "changed" nor "changes"
56+
- don't capitalize first letter
57+
- no dot (.) at the end
58+
59+
#### Body
60+
61+
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes".
62+
The body should include the motivation for the change and contrast this with previous behavior.
63+
64+
#### Footer
65+
66+
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
67+
68+
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
69+
The rest of the commit message is then used for this.
70+
71+
#### Examples
72+
73+
```commit
74+
fix(pencil): stop graphite breaking when too much pressure applied
75+
```
76+
77+
```commit
78+
feat(pencil): add 'graphiteWidth' option
79+
80+
Fix #42
81+
```
82+
83+
```commit
84+
perf(pencil): remove graphiteWidth option
85+
86+
BREAKING CHANGE: The graphiteWidth option has been removed.
87+
88+
The default graphite width of 10mm is always used for performance reasons.
89+
```

0 commit comments

Comments
 (0)