Branch Management

For each project, we are using a two branch strategy for active development.

master: The master branch represents the stable version of the repository. Documentation should be current with the master branch codebase. Consumers of the platform should use either the master branch or the published artifacts.
develop: Each repository has a "develop" branch. Active work is done on the develop branch. CI builds reference the develop branch. Work should not be merged from develop to master unless it is ready for release and the documentation will soon be updated (for example, at the end of an iteration).
1. bug fixes: We don't have a strategy in place yet for bug fixes and patches. At this point in time, bug fixes should be done on the develop branch.
prior release: As needed, a prior release that needs to be supported should be branched from master without the intention of merging back to master. For example, to move to a new version of the persistence tier, a prior release should be created to support the old version. The old version is never going to merge into master because the old persistence tier is not compatible.

Initial setup of develop branch

A pull request can easily be created in Bitbucket to merge from the develop branch to the master branch.

git checkout master
git pull
git merge develop -m "Merged from develop"
git push -u origin master
git checkout develop
git pull

Or, in one line

git checkout master && git pull && git merge develop -m "Merged from develop" && git push -u origin master && git checkout develop && git pull