mirror of
https://github.com/kiwix/kiwix-android.git
synced 2025-08-03 10:46:53 -04:00
#1200 explain how the branching model will work post 2.5
This commit is contained in:
parent
a43e631de0
commit
e42a7320ae
@ -40,4 +40,17 @@ Our process for accepting changes operates by [Pull Request (PR)](https://help.g
|
||||
|
||||
1. Once you have integrated comments, or waited for feedback, a Lieutenant should merge your changes in!
|
||||
|
||||
### Branching
|
||||
|
||||
Our branching strategy is based on [this article](https://nvie.com/posts/a-successful-git-branching-model/) which we suggest you read.
|
||||
|
||||
+ **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
|
||||
+ **hotfix/** or hotfix/<username>/ any branch under this directory is an urgent fix to production, once a hotfix is merged to master (and tagged for release) it must also be merged to develop before being deleted
|
||||
|
||||
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.
|
||||
|
||||
Rebasing should be avoided.
|
||||
|
||||
_These guidelines are based on [Tools for Government Data Archiving](https://github.com/edgi-govdata-archiving/overview/blob/master/CONTRIBUTING.md)'s._
|
||||
|
Loading…
x
Reference in New Issue
Block a user