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
changed and why. Follow these guidelines when writing one:
1. The first line should be 50 characters or less and contain a short
description of the change. All words in the description should be in
lowercase with the exception of proper nouns, acronyms, and the ones that
refer to code, like function/variable names. The description should
be prefixed with the name of the changed subsystem and start with an
imperative verb. Example: "net: add localAddress and localPort
to Socket"
1. The first line should:
- contain a short description of the change
- be 50 characters or less
- be entirely in lowercase with the exception of proper nouns, acronyms, and
the words that refer to code, like function/variable names
- be prefixed with the name of the changed subsystem and start with an
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.
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:
@ -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
72 characters or so. That way, `git log` will show things
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
Refs: http://eslint.org/docs/rules/space-in-parens.html
Refs: https://github.com/nodejs/node/pull/3615
```
### Step 4: Rebase
@ -203,9 +203,6 @@ core modules.
$ 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.
### Step 7: Discuss and update