Update commitstyle and contributing

CONTRIBUTING.md

@@ -46,11 +46,13 @@ Our branching strategy is based on [this article](https://nvie.com/posts/a-succe
 
 + **master** a history of releases, once merged to from develop and tagged we create a release on the play store & GitHub releases.
 + **develop**  the actively worked on next release of the app, what we branch off of while working on new features and what we merge into upon feature completion
-+ **feature/** or feature/\<username\>/ any branch under this directory is an actively developed feature, feature branches culminate in a PR, are merged and deleted. Typically a feature branch is off of develop and into develop but in rare scenarios if there is an issue in production a branch may be made off master to fix this issue, this type of feature branch must be merged to develop and master before being deleted.
++ **feature/** or feature/\<username\>/ any branch under this directory is an actively developed feature, feature branches culminate in a PR, are merged and deleted.
+ Typically a feature branch is off of develop and into develop but in rare scenarios if there is an issue in production a branch may be made off master to fix this issue, this type of feature branch must be merged to develop and master before being deleted.
+Branch names should be in the format **#\<issue-number\>-kebab-case-title**
 
-All branches should have distinct history and should be visually easy to follow, for this reason only preform merge commits when merging code either by PR or when synchronising.
+All branches should have distinct history and should be visually easy to follow, for this reason only perform merge commits when merging code either by PR or when synchronising.
 
-Rebasing should be avoided.
+If you wish to rebase you should be following the [Golden Rule](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing) and ahere to the advice in the heading [Aside: Rebase as cleanup is awesome in the coding lifecycle](https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase).
 
 ### Building
 

docs/commitstyle.md

@@ -1,46 +1,9 @@
 # Commit Style Guidelines for Kiwix-Android
 
 ### Message Structure
-Commit messages consist of three distinct parts, separated by a blank line: the title, an optional body/content, and an optional footer/metadata. The layout looks like this:
+Commit messages should be in the following format:
 
-type subject
+    #<issue-number> A brief description of changes on one line
-
-body
 
 ***
 
-### Title
-The title consists of the subject and type of the commit message.
-
-### Type
-The type is contained within the title and can be one of the following types:
-
-* **Implement** feature x
-* **Fix** a bug in x feature
-* **Improve** documentation for x feature
-* **Remove** removed redundant code
-* **Restyle** formatting, missing semi-colons, etc; no code change
-* **Refactor** refactoring production code
-
-### Subject
-The subject is a single short line summarising the change. It should be no greater than 50 characters, should begin with a capital letter and do not end with a period.
-
-Use an imperative tone to describe what a commit does, rather than what it did. For example, use fix; not fixed or fixes or fixing.
-
-For example:
-- Fix typo in Commit Style guidelines
-- Add crash reporting via e-mail
-- Implement SearchActivity using MVP pattern
-
-Instead of writing the following:
-- Fixed bug with Y
-- Changing behaviour of X
-
-### Body
-The body includes the kind of information commit message (if any) should contain.
-
-Not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is self-explanatory and no further context is necessary, therefore it is optional. The body is used to explain the what and why of a commit, not the how.
-
-When writing a body, the blank line between the title and the body is required and we should try to limit the length of each line to no more than 72 characters.
-
-***