gunghogeoduck/osem-fcy
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Update commit section in CONTRIBUTING.md

Browse source 
to improve the commit messages of future contributors and follow best practices.
This commit is contained in:
Christian Bruckmayer 2017-03-17 15:54:23 +01:00
parent 125a7fe29a
commit 06d9a0e396
No known key found for this signature in database
GPG key ID: 168295FC108C44E5
1 changed files with 16 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

29
CONTRIBUTING.md
View file

@ -85,19 +85,22 @@ You can access the app [localhost:3000](http://localhost:3000). Whatever you cha
* If not, please first leave a comment on how you want to implement it and wait for contributors' feedback * If not, please first leave a comment on how you want to implement it and wait for contributors' feedback
### Commits ### Commits
* Commit title should be short and descriptive * The commit title should be short and descriptive, and it should follow these rules:
* title (or summary line) is the first line of the commit message * It should be the first line of the commit message
* that says what the commit is doing * It explains what the commit does in the imperative mood (Fix foobar)
* in no more than 50 characters * It's no longer than 50 characters
* starting with a word like 'Fix' or 'Add' or 'Change' * It starts with a word like 'Fix' or 'Add' or 'Change'
* **without** a period (.) at the end * It does not end with a period (.)
* followed by a blank line * It is followed by a blank line
* Commit messages are * It should contain more than only the reference to the issue
* up to 72 characters
* with break lines Read this [article](https://chris.beams.io/posts/git-commit/) for more information
* Reference the issue(s) the commit closes * The commit message should follow these rules:
* https://help.github.com/articles/closing-issues-via-commit-messages * It should explain why the change is made
* If you haven't done so since the beginning, you should reference the issue when you squash your commits * It should not describe how the change is made, code is generally self-explanatory
* It's not longer than 72 characters
* It should contain line breaks
* It should contain a [reference](https://help.github.com/articles/closing-issues-via-commit-messages) to the issue
### Pull Requests workflow ### Pull Requests workflow
Please open a pull request (PR) only when you have finished coding, and your changes are ready to be reviewed for merging. Please open a pull request (PR) only when you have finished coding, and your changes are ready to be reviewed for merging.