diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e1e594832..d388dc72f 100644 --- a/CONTRIBUTING.md +++ b/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/\/ 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/\/ 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 **#\-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 diff --git a/docs/commitstyle.md b/docs/commitstyle.md index c449fc434..445affe26 100644 --- a/docs/commitstyle.md +++ b/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 - -body + # A brief description of changes on one line *** -### 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. - -***