Skip to content

Using SAM with Git and GitHub

Brian Mirletz edited this page Dec 3, 2021 · 3 revisions

Contents

Git basics

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

SAM's Git workflow

Work for an upcoming release should be completed in feature branches created from the develop branch. Work for a patch to an existing release should be completed in hotfix branches created from the patch branch.

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. If your issue is tagged with a patch milestone, then merge the changes into the patch branch. Do not merge develop into patch, if you created a branch from develop but it needs to be merged into patch, cherry-pick the relevant commits to a new branch created from patch.

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
  • master - the code which has been released. After the develop branch is completely polished for an annual release, it should be merged into master and tagged.
  • patch - a branch from master containing changes to be released in the next patch. Commits on this branch will be tagged with patch releases as they are deployed (typically two or three per year). This corresponds to the "release" branch in the diagram below.
  • hotfixes - a hotfix branch can be created from patch if there are immediate patch issues to address in the released code. Once the code is corrected, the branch can be merged into patch and develop, and the branch deleted.

Modified from: http://nvie.com/posts/a-successful-git-branching-model/