Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

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

  1. 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.  
  2. 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. 
  3. 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

Merge from develop to master

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
  • No labels