Skip to content

Commit

Permalink
doc: make commit guidelines easier to reference
Browse files Browse the repository at this point in the history
- Can now link to 'Commit Guidelines' from pull requests
- Breaks up commit requirements and recommendations

PR-URL: #11732
Refs: #11723 (comment)
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
  • Loading branch information
bf4 authored and MylesBorins committed May 18, 2017
1 parent b53d172 commit 2b6e588
Showing 1 changed file with 20 additions and 23 deletions.
43 changes: 20 additions & 23 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,15 +98,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:

Expand All @@ -121,22 +134,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
Expand Down Expand Up @@ -200,9 +200,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
Expand Down

0 comments on commit 2b6e588

Please sign in to comment.