Git workflow
mSupply Mobile development uses the GitFlow branching model.
mSupply Mobile development is based on two main branches: master and develop:
-
master- latest stable release.
- tested and documented.
-
develop- latest development version.
- features may need testing and/or documenting.
Development on new features should be done in a feature branch based on develop. When a feature is completed, it should be merged back into the develop branch. The naming convention for feature branches is feature/my-feature-name, e.g.:
git checkout develop
git checkout -b feature/my-cool-feature
To work on a feature, branch off the feature branch with the name of the issue being worked on, e.g.
git checkout feature/my-cool-feature
git checkout -b "feature/my-cool-feature/#1-add-my-cool-method"
When work is completed, a pull request should be made to the feature branch.
In exception circumstances, fixes for high priority bugs may skip the develop stage and be merged directly into the master branch.
To work on a hotfix, branch off the master branch with the name of the hotfix being worked on, e.g.
git checkout master
git checkout -b "hotfix/#2-my-emergency-fix"
When work is completed, a pull request should be made directly to the master branch.
One of the main benefits of GitFlow is that it enables new development to be isolated from finished work, making parallel development a lot easier. Release branches represent "alpha" candidates for a particular version, and enable developers to "lock down" a release while continuing development work on new functionality, e.g.
git checkout develop
git checkout -b "2.1.0-rc10"
Release branches should always be branched from develop branch, and are considered "dirty" until they are thoroughly tested and bug fixed, at which point they can be tagged and merged into master.