2c7b4fb449
It turned out in #271 that the current description for commit messages introducing breaking changes is not clear enough.
76 lines
2.5 KiB
Markdown
76 lines
2.5 KiB
Markdown
# Contributing to Hyper
|
|
|
|
You want to contribute? You're awesome! When submitting a Pull Request, please have your commits follow these guidelines:
|
|
|
|
## Git Commit Guidelines
|
|
|
|
These guidelines have been copied from the [AngularJS](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#-git-commit-guidelines)
|
|
project.
|
|
|
|
We have very precise rules over how our git commit messages can be formatted. This leads to **more
|
|
readable messages** that are easy to follow when looking through the **project history**. But also,
|
|
we use the git commit messages to **generate the change log**.
|
|
|
|
### Commit Message Format
|
|
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
|
|
format that includes a **type**, a **scope** and a **subject**:
|
|
|
|
``
|
|
<type>(<scope>): <subject>
|
|
<BLANK LINE>
|
|
<body>
|
|
<BLANK LINE>
|
|
<footer>
|
|
``
|
|
|
|
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
|
|
to read on github as well as in various git tools.
|
|
|
|
### Type
|
|
Must be one of the following:
|
|
|
|
* **feat**: A new feature
|
|
* **fix**: A bug fix
|
|
* **docs**: Documentation only changes
|
|
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing
|
|
semi-colons, etc)
|
|
* **refactor**: A code change that neither fixes a bug or adds a feature
|
|
* **perf**: A code change that improves performance
|
|
* **test**: Adding missing tests
|
|
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
|
|
generation
|
|
|
|
### Scope
|
|
The scope should refer to a module in hyper that is being touched. Examples:
|
|
|
|
* headers
|
|
* client
|
|
* server
|
|
* http
|
|
* method
|
|
* net
|
|
* status
|
|
* version
|
|
|
|
### 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 dot (.) 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.
|
|
|
|
###Footer
|
|
The footer should contain any information about **Breaking Changes** and is also the place to
|
|
reference GitHub issues that this commit **Closes**.
|
|
|
|
The last line of commits introducing breaking changes should be in the form `BREAKING_CHANGE: <desc>`
|
|
|
|
|
|
A detailed explanation can be found in this [document][commit-message-format].
|
|
|
|
[commit-message-format]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
|