-
Notifications
You must be signed in to change notification settings - Fork 4
Origami Branch Structure
Dan edited this page Oct 24, 2015
·
1 revision
Here is the proposed procedure as of 10/24/15:
- The master branch is always to be considered unstable and experimental. Use this at your own risk for production-level analyses
- For stable sets of code, look at the tagged (release) section and download that
- With that said, ideally the master branch should be kept in a runnable and editable state, although it may not be 100% analytically correct or ready to run. Otherwise, this may prevent others from working on individual updates. If the master branch is broken, it should be fixed by placing in back into some state that others could clone the repository and further edit the software
- Most work should be conduced in branches and then merged back into master (via pull requests)
- In general, branches should be named informatively to whoever is the primary person or by the intended feature update
- The exception is that each release should have a branch for version-specific bugfixes, which may be long-running and merged back into the master branch at multiple points in time