docs: Add commit message format guide

This is important in order for `git log` and `gitk` to work properly.

* Mostly as inspired by the master himself:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/

* Other sources:

https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message
https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting

Author: ukkopahis

docs/Developers/index.md

@@ -52,6 +52,45 @@ Services will grow over time, we may split up the buildstack menu into subsectio
 * Any configs that are required before getting the service running should be configured in the service's options menu (and a BuildStack menu Issue should be displayed if not).
 * Fork the repo and push the changes to your fork. Create a cross repo PR for the mods to review. We may request additional changes from you.
 
+## Commit message
+
+```
+service_name: Add/Fix/Change feature or bug summary
+
+Optional longer description of the commit. What is changed and why it
+is changed. Wrap at 72 characters.
+
+* You can use markdown formating as this will automatically be the
+  description of your pull-request.
+* End by adding any issues this commit fixes, one per line:
+
+Fixes #1234
+Fixes #4567
+```
+
+1.  The first line is a short description. Keep it short, aim for 50
+    characters. This is like the subject of an email. It shouldn't try to fully
+    or uniquely describe what the commit does. More importantly it should aim
+    to inform *why* this commit was made.
+
+    `service_name` - service or project-part being changed, e.g. influxdb,
+    grafana, docs. Documentation changes should use the the name of the
+    service. Use `docs` if it's changes to general documentation. If all else
+    fails, use the folder-name of the file you are changing. Use lowercase.
+
+    `Add/Fix/Change` - what type of an change this commit is. Capitalized.
+
+    `feature or bug summary` - free very short text giving an idea of why/what.
+
+2. Empty line.
+
+3.  A longer description of what and why. Wrapped to 72 characters.
+
+    Use [github issue linking](
+    https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)
+    to automatically close issues when the pull-request of this commit is
+    merged.
+
 ## Follow up
 If your new service is approved and merged then congratulations! Please watch the Issues page on github over the next few days and weeks to see if any users have questions or issues with your new service.