Branching strategy

[goodmami]

See #502 for some context.

The old pattern of having someone work on a branch for months or years before merging wholesale is becoming difficult to manage. More specifically:

• the task of reviewing the pull request becomes gargantuan
• divergences in the code increases the likelihood of conflicts
• it is harder to notice when a merge would obliterate changes made since the branch was created

We should probably aim for smaller, more ephemeral branches that get merged quickly and then pruned. The problem with this is the possibility of merging partial features that get deployed to the live site.

This issue is about discussing and choosing a branching model and related practices to be documented in the CONTRIBUTING.md file or to a wiki.

[goodmami]

For a branching model we might take inspiration from GitFlow or the simpler GitHub Flow. One question is whether we need separate "trunk" and "live" branches (akin to "develop" and "master" in GitFlow)?

One proposal:

1. Trivial commits that don't affect code (e.g., typos in documentation) can be pushed to trunk without a pull request
2. Anything else needs a branch and a PR (or multiple)
3. A major change, such as a new phenomenon library, should be tracked by a project board instead of a branch
   a. related issues are tracked on the board
   b. multiple branches and pull requests may be created and merged along the way
   c. accumulated but non-disruptive changes, such as code infrastructure or new (probably skipped) regression tests, can be merged to trunk
   d. disruptive changes, such as activating a new feature in the customization system or on the questionnaire, should not be merged until they are ready, but the creator should keep the branch in sync with trunk to reduce merge conflicts later
   e. when the project is complete, create a tag
4. For the live site, either:
   a. keep a separate live branch that is updated to the state of trunk when it is stable, or
   b. create a tag/release when trunk is stable and deploy then; at any point, a user may create an instance by deploying from the latest release