Git Branching Strategy
Rock is using a branching model described by Vincent Driessen now called Gitflow. You can read more about Gitflow and Vincent’s corresponding Git extensions on the GitHub git-flow project. There is also a good 6 minute high-level overview video if Gitflow is new to you.
Once you have an understanding of Gitflow, read our Git Branching document which describes in detail exactly how we want you to operate.
Type | Format | Example
---- | ------ | -------
Feature | feature-[your_initials]-[name-of-feature] | feature-drt-add-campus
Release | release-[version-number] | release-1.0
Hotfix | hotfix-[version-number] | hotfix-1.0.1
Custom | custom-[organization domain] | custom-ccvonline
Use this information to assist you with understanding what you should be using in your environment.
Name | Description
---- | ------------
develop | This is our main develop trunk and it's where the latest features are going for future, upcoming releases.
pre-alpha-spark | This is branch is merged from `develop` weekly (most of the time) and is typically deployed to the rockrms.com site on Sunday/Monday evening/morning. This is a good example of us eating-our-own-dogfood.
pre-alpha-release | This is branched from `pre-alpha-spark` a week later (typically) on Mondays. If you're a developer with a boss who understands the risks involved, you could run off this branch -- but you're on the leading, bleading edge here.
release-x.y.z | These branches are typically the most stable and are typically unchanging once we move from [Alpha Testing](http://www.rockrms.com/page/473?Item=51) to [Beta Testing](http://www.rockrms.com/page/473?Item=91). Once we're in beta testing, we typically create a hotfix-x.y.z+1 branch to address issues and critical fixes. Depending on the length and success of our [Beta tester's](http://www.rockrms.com/page/473?Item=91) testing, this branch usually gets released after 4-8 weeks. See the [ReleaseNotes page](http://www.rockrms.com/ReleaseNotes) for release date history.
hotfix-x.y.z | These branches are created once we've collected and corrected enough bugs or critical fixes to justify the overhead and cost.
Setting up Your Rock Environment to Use a Weekly Build of the "pre-alpha-release" Branch
We normally recommend everyone use the released, packaged updates in their production Rock system. This is always a safe bet. However, to a few others, we might suggest using the pre-alpha-release branch. If you think running your production Rock environment off that branch is a bad idea – you may be correct. It could be a terrible idea if you don't have someone on your team who: A) knows how to manage this risk and B) who has the needed skills to pull off this feat. You'll need a developer who's very comfortable with git and github, and a director who understands the pros and cons of taking this approach.
The main reasons are:
- You'll have access to the latest and, often, greatest version of Rock.
- You'll get bug fixes almost as soon as they’re written.
- You're doing a service to others by using the latest code base in your production environment so you can catch, report and possibly fix issues before anyone else.
There are a few cons however you need to be aware of:
- New features will appear that are not yet documented.
- New bugs could appear that have not been reported yet.
- You could miss a database change (aka "data migration").
- You could really, really mess up your system if you do something wrong.