1 | Contribution Guide for Manhattan Project
|
2 | ========================================
|
3 |
|
4 | ## Git Commit Guidelines
|
5 |
|
6 | These guidelines have been copied from the [AngularJS](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines)
|
7 | project.
|
8 |
|
9 | We have very precise rules over how our git commit messages can be formatted. This leads to **more
|
10 | readable messages** that are easy to follow when looking through the **project history**. But also,
|
11 | we use the git commit messages to **generate the change log**.
|
12 |
|
13 | ### Commit Message Format
|
14 | Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
15 | format that includes a **type**, a **scope** and a **subject**:
|
16 |
|
17 | ```
|
18 | <type>(<scope>): <subject>
|
19 | <BLANK LINE>
|
20 | <body>
|
21 | <BLANK LINE>
|
22 | <footer>
|
23 | ```
|
24 |
|
25 | Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
|
26 | to read on github as well as in various git tools.
|
27 |
|
28 | ### Type
|
29 | Must be one of the following:
|
30 |
|
31 | * **feat**: A new feature
|
32 | * **fix**: A bug fix
|
33 | * **docs**: Documentation only changes
|
34 | * **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
|
35 | semi-colons, etc)
|
36 | * **refactor**: A code change that neither fixes a bug or adds a feature
|
37 | * **perf**: A code change that improves performance
|
38 | * **test**: Adding missing tests
|
39 | * **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
|
40 | generation
|
41 |
|
42 | ### Scope
|
43 | In our project scope refers to BEM block which is touched by changes.
|
44 |
|
45 | ### Subject
|
46 | The subject contains succinct description of the change:
|
47 |
|
48 | * use the imperative, present tense: "change" not "changed" nor "changes"
|
49 | * don't capitalize first letter
|
50 | * no dot (.) at the end
|
51 |
|
52 | ###Body
|
53 | Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
|
54 | The body should include the motivation for the change and contrast this with previous behavior.
|
55 |
|
56 | ###Footer
|
57 | The footer should contain any information about **Breaking Changes** and is also the place to
|
58 | reference GitHub issues that this commit **Closes**.
|
59 |
|
60 | The last line of commits introducing breaking changes should be in the form `BREAKING_CHANGE: <desc>`
|
61 |
|
62 |
|
63 | A detailed explanation can be found in this [document][commit-message-format].
|
64 |
|
65 | [commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
|
66 |
|
67 | ## Pull Request reviews comments
|
68 |
|
69 | Following abbreviations should be used in PR merge comments:
|
70 |
|
71 | * `r+ {sha}`: review passed for all commits up to `{sha}`
|
72 | * `r-`: review revealed some errors, changes must be done to proceed
|
73 | * `r? @spanferov`: request for review from another user
|
74 | * `re-r? @spanferov`: request another user to do review again
|
75 | * `cc @spanferov, @smbd`: current message is also intended for...
|