Suggested workflow using 'development' branch in opentree repo

Workflow involving a development branch (currently only in the opentree repo)

In IRC discussion 2015-01-08 it became clear that we could benefit from having a 'development' branch for the opentree repo, so that multiple features could be deployed even if not merged to master yet and even if some features developed in between have been merged to master. The goal here is mainly to facilitate review of multiple features without having to switch devtree between feature branches (which is not really practical during a short PR review session).

According to this workflow you always deploy the development branch, not a feature branch, to devtree. If you forget to merge a feature to development, and use the old workflow, nothing terrible happens, but no one gets the benefit of having the feature coexist with other features in testing. Your PR might get rejected or tabled during review, if the reviewers want to look at it live and the feature has been overwritten on devtree by deployment of another branch (such as development).

When developer Z works on a new feature:

1. Z creates a new feature branch F, as before, with master (not development) as its upstream branch
2. While reviewers not satisfied:
   1. While Z not satisfied:
      1. Iterate:
         1. Z edits files and commit to F
         2. Z tests locally or on private server to extent possible
      2. [Optional: Z refreshes 'development' branch from github (pull or fetch/merge).]
      3. [Optional: Z refreshes 'master' from github and merges to 'development'.]
      4. Z merges F to local 'development', without changing its upstream.
      5. Z pushes 'development' to github.
      6. Z deploys the new feature from the development branch. (assuming germinator repo and deployed-systems repo are in sibling directories:) cd {path-to-germinator-clone}/deploy; ./push.sh -c ../../deployed-systems/development/devtree.config
      7. [the .config file is set up to deploy the 'development' branch of github opentree repo to devtree]
      8. Z reviews changes (by accessing devtree.opentreeoflife.org)
   2. Z pushes branch F to github
   3. Z submits PR for branch F
   4. Reviewers review the PR (looking at devtree.opentreeoflife.org)
3. Reviewers merge the F branch PR (to 'master') using github UI
4. [Anyone deletes github branch F]
5. Production-meister deploys 'master' to production server

Other developers (X, Y, …) can use the same procedure for their work; branch ‘development’ can have all their current work merged for review, since the ‘development' branch is never merged to someplace else.