|
|
|
# General notes on hivemind development process
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
## Coding conventions
|
|
|
|
|
|
|
|
* 2 space indention (DO NOT USE TABS)
|
|
|
|
* Avoid the use of acronyms and abbreviations in source code (i.e. in variable names) and file names unless it is standard abbreviation/acronym of the English language. |
|
|
|
\ No newline at end of file |
