| This document summarizes a discussion that took place on the "dev" ML: |
| http://markmail.org/message/7lnus64entdwj4vo |
| |
| The conclusions reported here are based on ideas presented in this blog post: |
| http://nvie.com/posts/a-successful-git-branching-model/ |
| |
| 1. The "master" branch can only contain released code; i.e. the only |
| accepted commits are the result of a merge from the "release" branch |
| (from a release candidate that passed a vote). |
| 2. Contents that is candidate for being released must be merged into the |
| "release" branch, from the "develop" branch. |
| 3. The "develop" branch collects all modifications that will be part |
| of the next release. |
| Usually, changes should not be committed directly to the "develop" |
| branch; they should be merged from a branch specifically created for |
| that purpose (see next point). |
| 4. Work on an identified issue (bug fix or new feature) must be done in a |
| new branch named after its corresponding report in the bug-tracking |
| system (JIRA), e.g. "feature-MATH-1319". |
| After completion, and in the absence of technical objections, the feature |
| branch is merged into the "develop" branch, using the "--no-ff" git |
| option. |
| That feature branch is then deleted. |
