1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: make commit guidelines easier to reference

Browse Source 
- Can now link to 'Commit Guidelines' from pull requests
- Breaks up commit requirements and recommendations

PR-URL: https://github.com/nodejs/node/pull/11732
Refs: https://github.com/nodejs/node/pull/11723#issuecomment-284556146
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
This commit is contained in:
Benjamin Fleischer 2017-03-07 10:00:27 -06:00 committed by Gibson Fahnestock
parent 200961b7e1
commit bd97e48d9a
No known key found for this signature in database
GPG Key ID: B01FBB92821C587A
1 changed files with 20 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
CONTRIBUTING.md
View File

@ -100,15 +100,28 @@ $ git commit
Writing good commit logs is important. A commit log should describe what Writing good commit logs is important. A commit log should describe what
changed and why. Follow these guidelines when writing one: changed and why. Follow these guidelines when writing one:
1. The first line should be 50 characters or less and contain a short 1. The first line should:
description of the change. All words in the description should be in - contain a short description of the change
lowercase with the exception of proper nouns, acronyms, and the ones that - be 50 characters or less
refer to code, like function/variable names. The description should - be entirely in lowercase with the exception of proper nouns, acronyms, and
be prefixed with the name of the changed subsystem and start with an the words that refer to code, like function/variable names
imperative verb. Example: "net: add localAddress and localPort - be prefixed with the name of the changed subsystem and start with an
to Socket" imperative verb. Examples: "net: add localAddress and localPort
to Socket", "src: fix typos in node_lttng_provider.h"
- be meaningful; it is what other people see when they
run `git shortlog` or `git log --oneline`.<br>
Check the output of `git log --oneline files/you/changed` to find out
what subsystem (or subsystems) your changes touch
2. Keep the second line blank. 2. Keep the second line blank.
3. Wrap all other lines at 72 columns. 3. Wrap all other lines at 72 columns.
- If your patch fixes an open issue, you can add a reference to it at the end
of the log. Use the `Fixes:` prefix and the full issue URL. For other references
use `Refs:`. For example:
```txt
Fixes: https://github.com/nodejs/node/issues/1337
Refs: http://eslint.org/docs/rules/space-in-parens.html
Refs: https://github.com/nodejs/node/pull/3615
```
A good commit log can look something like this: A good commit log can look something like this:
@ -123,22 +136,9 @@ The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about please do proper word-wrap and keep columns shorter than about
72 characters or so. That way, `git log` will show things 72 characters or so. That way, `git log` will show things
nicely even when it is indented. nicely even when it is indented.
```
The header line should be meaningful; it is what other people see when they
run `git shortlog` or `git log --oneline`.
Check the output of `git log --oneline files_that_you_changed` to find out
what subsystem (or subsystems) your changes touch.
If your patch fixes an open issue, you can add a reference to it at the end
of the log. Use the `Fixes:` prefix and the full issue URL. For other references
use `Refs:`. For example:
```txt
Fixes: https://github.com/nodejs/node/issues/1337 Fixes: https://github.com/nodejs/node/issues/1337
Refs: http://eslint.org/docs/rules/space-in-parens.html Refs: http://eslint.org/docs/rules/space-in-parens.html
Refs: https://github.com/nodejs/node/pull/3615
``` ```
### Step 4: Rebase ### Step 4: Rebase
@ -203,9 +203,6 @@ core modules.
$ git push origin my-branch $ git push origin my-branch
``` ```
Go to https://github.com/yourusername/node and select your branch.
Click the 'Pull Request' button and fill out the form.
Pull requests are usually reviewed within a few days. Pull requests are usually reviewed within a few days.
### Step 7: Discuss and update ### Step 7: Discuss and update