Update CONTRIBUTING.md

Add commit message style guidelines to CONTRIBUTING.md

Relates-to: OLPEDGE-302

Signed-off-by: Kateryna Osadchenko <[email protected]>

Author: ksenteer

CONTRIBUTING.md

@@ -1,5 +1,9 @@
 # HERE OLP SDK for C++ Contributor Guide
 
+### Contributing to HERE OLP SDK for C++
+
+First off, thanks for taking the time to contribute! The team behind the [HERE OLP SDK for C++](https://github.com/heremaps/here-olp-sdk-cpp) gratefully accepts contributions via [pull requests](https://help.github.com/articles/about-pull-requests/) filed against the [GitHub project](https://github.com/heremaps/here-olp-sdk-cpp/pulls). As part of filing a pull request we ask you to sign off the [Developer Certificate of Origin](https://developercertificate.org/) (DCO).
+
 ## Development
 
 ### Code Style
@@ -102,6 +106,26 @@ If you need to format all `.cpp` and `.h` files in a directory recursively, you
 find foo/bar/ -iname *.h -o -iname *.cpp | xargs clang-format -i --style=file
 ```
 
+### Style Guidelines for Commit Messages
+
+We strive to maintain a high software quality standard and strongly encourage contributions to keep up the following guidelines. 
+In general, we share the view on how a commit message should be written with the [the Git project itself](https://github.com/git/git/blob/master/Documentation/SubmittingPatches).
+
+- [Make separate commits for logically separate changes.](https://github.com/git/git/blob/e6932248fcb41fb94a0be484050881e03c7eb298/Documentation/SubmittingPatches#L43) For example, simple formatting changes that do not affect software behavior usually do not belong in the same commit as changes to program logic.
+- [Describe your changes well.](https://github.com/git/git/blob/e6932248fcb41fb94a0be484050881e03c7eb298/Documentation/SubmittingPatches#L101) Do not just repeat in prose what is "obvious" from the code, but provide a rationale explaining why you believe your change is necessary.
+- [Describe your changes in the imperative mood and present tense.](https://github.com/git/git/blob/e6932248fcb41fb94a0be484050881e03c7eb298/Documentation/SubmittingPatches#L133) Instead of writing "Fixes an issue with encoding" prefer "Fix an encoding issue". Think about it like the commit only does something if it is applied. Such approach usually results in more concise commit messages.
+- [We are picky about whitespaces.](https://github.com/git/git/blob/e6932248fcb41fb94a0be484050881e03c7eb298/Documentation/SubmittingPatches#L95) Trailing whitespace and duplicate blank lines are simply an annoyance, and most Git tools flag them red in the diff anyway. We generally use four spaces for indentation in TypeScript code, and two spaces for indentation in JSON / YAML files.
+
+- Limit the first line to 72 characters or less.
+- If you ever wondered how a nearly "perfect" commit message looks like, have a look at one of [Jeff King's commits](https://github.com/git/git/commits?author=peff) in the Git project for references and ideas.
+- When you address a review comments in a pull request, please fix the issue in the commit where it appears, not in a new commit on top of the pull request's history. While this requires force-pushing of the new iteration of you pull request's branch, it has several advantages:
+  - Reviewers that go through (larger) pull requests commit by commit are always up-to-date with latest fixes, instead of coming across a commit that addresses one of possibly also their remarks only at the end.
+  - It maintains a cleaner history without distracting commits like "Address review comments".
+  - As a result, tools like [git-bisect](https://git-scm.com/docs/git-bisect) can operate in a more meaningful way.
+  - Fixing up commits allows for making fixes to commit messages, which is not possible by only adding new commits.
+- If you are unfamiliar with fixing up existing commits, please read about [rewriting history](https://git-scm.com/book/id/v2/Git-Tools-Rewriting-History) and git rebase --interactive in particular.
+- To resolve conflicts, rebase pull request branches onto their target branch instead of merging the target branch into the pull request branch — such approach results in a cleaner history without "criss-cross" merges.
+
 ### Design Guidelines
 
 * Follow the **SOLID** design principles: