|
| 1 | +# Contributing to `gren` 🍺🤖👍 |
| 2 | + |
| 3 | +❤️ Thanks for contributing to this project. |
| 4 | +Following, you can find a couple of things to keep in mind before contributing to gren. |
| 5 | + |
| 6 | + |
| 7 | +1. [Issues](#issues) |
| 8 | +2. [Commits](#commits) |
| 9 | +3. [Branches](#branches) |
| 10 | +4. [Pull Requests](#pull-requests) |
| 11 | + |
| 12 | +## Issues |
| 13 | + |
| 14 | +Every piece of work has to be related to an issue. |
| 15 | +The issue will have a capitalised title, which follows the same rules of [commits messages](#commits). |
| 16 | + |
| 17 | +Every issue should contain one label that reflects the issue category. |
| 18 | +If the issue is going to be close with no development, use one of these labels: |
| 19 | + |
| 20 | +- `wontfix` |
| 21 | +- `can't replicate` |
| 22 | +- `gren ignore` |
| 23 | +- `invalid` |
| 24 | +- `duplicate` |
| 25 | + |
| 26 | +When a task is completed, create a [Pull Request](#pull-requests) which closes the issue. |
| 27 | + |
| 28 | +## Commits |
| 29 | + |
| 30 | +1. Start the subject line with a verb (e.g. **Change** header styles) |
| 31 | +2. Use the imperative mood in the subject line (e.g. **Fix**, not _Fixed_ or _Fixes_ header styles) |
| 32 | +3. Limit the subject line to about 50 characters |
| 33 | +4. Do not end the subject line with a period |
| 34 | +5. Separate subject from body with a blank line |
| 35 | +6. Wrap the body at 72 characters |
| 36 | +7. Use the body to explain what and why vs. how |
| 37 | + |
| 38 | +## Branches |
| 39 | + |
| 40 | +For every piece of development, create a branch. The naming convention for the branch is `lowercases-with-dashes`. |
| 41 | +Branch off `master` rebase on top of `master` and create a PR back to `master`. |
| 42 | + |
| 43 | +The branch will be deleted straight after the pull request. |
| 44 | + |
| 45 | +## Pull Requests |
| 46 | + |
| 47 | +A PR has to close at least one issue and preferably only one. The less amount of work is in one PR, the easier is to review it. |
| 48 | + |
| 49 | +The body of the PR should start with a [message that closes the related issues](https://help.github.com/articles/closing-issues-via-commit-messages/) and the actual description in a new lines. |
| 50 | + |
| 51 | +The commit history in a PR should not contain `Merge` commits and should be rebased on top of `master`. |
| 52 | + |
| 53 | +It's easier to review the PR, if you rebase your commits so that every commit represents a sub-piece of the development and can be independently reviewed or a clear list of the features on that branch. |
| 54 | + |
| 55 | +e.g. |
| 56 | +``` |
| 57 | +Closes #123 |
| 58 | +
|
| 59 | +Here any further informations needed to the reviewer, e.g. run yarn before reviewing. |
| 60 | +``` |
| 61 | + |
| 62 | +### Checks |
| 63 | + |
| 64 | +Every PR has to be reviewed before can be merged in. |
| 65 | + |
0 commit comments