... | ... | @@ -2,7 +2,9 @@ |
|
|
|
|
|
## Branching methodology
|
|
|
|
|
|
Hivemind is being developed using a master/develop branching process. Production builds should always be made from the **master** branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the **develop** branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches. A side-effect of this is that someone should always be able to build a production node using the head of the master branch.
|
|
|
Hivemind is being developed using a master/develop branching process. Production builds should always be made from the **master** branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the **develop** branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches.
|
|
|
|
|
|
A side-effect of this is that someone should always be able to build a production node using the head of the master branch.
|
|
|
|
|
|
If you plan to commit your own remote branches to the repo (if you're working for more than a day or two in a branch, this is recommended), please add a prefix with your initials, so that a casual viewer of the branches list can see who is responsible for the branch.
|
|
|
|
... | ... | |