Include guide to good commits in CONTIRBUTING file

CONTRIBUTING

@@ -14,13 +14,6 @@ Contributing:
    actually working on it.  Open source requires thick skin.  Please don't be
    discouraged if your changes don't go through, learn from it and get better.
 
- - If you don't quite know what to work on and just want to help, the bug
-   tracker has a list of things that need to be worked on.
-
- - Try to respect the wishes of the author(s)/maintainer(s).  A good maintainer
-   will always listen, and will often ask others on the project for their
-   opinions, but don't expect things to be completely democratic.
-
  - Coding style is Linux-style KNF (kernel normal form).  This means K&R, 80
    columns max, preferable maximum function length of approximately 42 lines, 8
    character width tabs, lower_case_names, etc.  I chose this for the sake of
@@ -34,6 +27,14 @@ Contributing:
    encouraged (though not required) to distinguish it from C code.  Just a
    personal and subjective stylistic thing on my part.
 
+ - Commits are not just changes to code; they should also be treated as
+   annotation to code.  For that reason, do not put unrelated changes in a
+   single commit.  Separate out different changes in to different commits, and
+   make separate pull requests for unrelated changes.  Commits should be
+   formatted with the 50/72 standard, and should be descriptive and concise.
+   See http://chris.beams.io/posts/git-commit/ for a summary of how to make
+   good commit messages.
+
  - Core code is C only (unless there's an operating system specific thing that
    absolutely requires another language).
 
@@ -41,6 +42,13 @@ Contributing:
    to use C unless an API you're using requires C++ or Objective-C (such as
    windows COM classes, or apple Objective-C APIs).
 
+ - If you don't quite know what to work on and just want to help, the bug
+   tracker has a list of things that need to be worked on.
+
+ - Try to respect the wishes of the author(s)/maintainer(s).  A good maintainer
+   will always listen, and will often ask others on the project for their
+   opinions, but don't expect things to be completely democratic.
+
  - Do not use dependencies for the sake of convenience.  There's enough
    dependencies as it is.  Use them only if you absolutely have to depend on
    them.