From f3d1fa15ec1fdf9f4fceebb9622054c3757bc30b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mantas=20Mikul=C4=97nas?= <mantas@utenos-kolegija.lt>
Date: Fri, 10 Jun 2016 21:04:47 +0300
Subject: [PATCH] docs: Recommend the usual commit message rules
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It is much easier to review commits (e.g. with `tig`) if they have a
short subject line – e.g. a sysadmin might want to quickly skip all the
"docs: Foo" and "tests: Bar" commits and focus on the important parts.
---
 CONTRIBUTE.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/CONTRIBUTE.md b/CONTRIBUTE.md
index d30e499f3..0fd98ff5f 100644
--- a/CONTRIBUTE.md
+++ b/CONTRIBUTE.md
@@ -55,6 +55,12 @@ attention to:
 * Do not include many changes in every commit. Commits should be focused and address one single problem or feature. By
 having **multiple, small commits** instead of few large ones, it is easier to track what you are doing, revert changes
 in case of an error and help you out if needed.
+* Try to write clean **commit messages**, largely based on the [seven rules](http://chris.beams.io/posts/git-commit/):
+   * Write a **short** subject line, followed by a blank line and a longer explanation.
+   * Prefix the subject line with the component(s) changed, e.g. "docs: Update foo", or "SAML: Don't log bar twice",
+     or "tests: Add tests for quux".
+   * Explain **what and why** in the commit message, not just _how_. Things obvious now might become quite confusing
+     when rediscovered years later.
 * **Be explicit**. Add comments. Use strict comparison operators like `===` and check for specific values when testing
 conditions.
 * **Keep things simple**. Avoid big functions, long nested loops or `if` statements.
-- 
GitLab