Using SAM with Git and GitHub
The basics of Git and GitHub are described in the Git tutorial. This page will focus rather on the specifics of interacting with SAM through Git and GitHub desktop. The content is developed and modified from the excellent documentation of NREL's OpenStudio project on Git and GitHub
All work should be completed in feature branches created from the develop branch. Occasional branches will be created from develop to release# (where # is a to-be-determined version number). Once the release# branch is sufficiently tested and polished, it will be merged to master. Note, no commits or development work should be made to the release# or master branch unless you are authorized to modify.
Most users on a day-to-day basis should be working out of their own feature branch, test their changes, and then merge those changes into the develop branch once they are tested and working as expected.
As an overview of which branches are intended for what purpose:
- feature - branch to develop a specific feature, i.e, batterydev, separate from other efforts. This can be a branch that an individual always works out of, or a branch created for a specific purpose with the intent of later deletion.
- develop - the equivalent of the SVN development trunk, this is where the latest tested developed code lives
- release - a branch specifically created to encapsulate the features that will go in an upcoming release.
- master - the code which has been released. After the release branch is completely polished and ready to build, it should be merged into master and tagged.
- hotfixes - a hotfix branch can be created from master if there are immediate patch issues to address in the released code. Once the code is corrected, the branch can be merged into master and develop, and the branch deleted.
Modified from: http://nvie.com/posts/a-successful-git-branching-model/