|
|
@ -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 |
|
|
|