Skip to content
This repository has been archived by the owner on Aug 7, 2019. It is now read-only.

Branching

Nathan Thompson edited this page Dec 9, 2015 · 1 revision

The CukeFarm branching strategy is very simplistic. It consists of the following three types of branches:

Feature Branches

Feature Branches are used to develop new features. They should be named using a short phrase that is indicative of the feature under development. They are short-lived and are deleted after being merged into either a version branch or master.

Version Branches

Version Branches serve two purposes: 1) they act as staging grounds for features that will be included in the next major release, and 2) they provide a space to apply patches to old versions once the master branch has advanced to a new major version. They should be named using the pattern version-<major_version>. If the Version Branch is ahead of the current major version on the master branch, all feature branches containing upcoming breaking changes should be merged into the Version Branch. Once a new major version is ready to be published, the Version Branch corresponding to it should be merged into master and the new version should be tagged and published. If a patch needs to be applied to a major version behind what is currently on master, it should be developed on a Feature Branch which is then merged into the appropriate Version Branch. The patched release is then tagged on the Feature Branch and published.

master

master is the main CukeFarm branch. All feature branches containing non-breaking changes should be merged into this branch. All releases should be tagged and published from this branch, except where the release in question is patching a major version older than what is currently on master.

Clone this wiki locally