doc: make commit guidelines easier to reference

CONTRIBUTING.md

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