| 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...
|