Branch Management

The COmanage Project has adopted a modified version of git-flow as its branch management strategy. In short, the differences are

1. One hotfix branch exists per minor release. That is, hotfix-1.0.x is used for (eg) 1.0.1and1.0.2. While these will typically branch from and merge into master, they may also branch from any release tag, and may not merge into master if master has already moved on to a new minor (or major) release. Both master and hotfix-* should be deployable at all times.
2. Release branches are not currently used. All features for release merge into develop, which eventually merges into master to create a release tag.
3. Feature branches (topic branches) are optional and should be named for the corresponding JIRA issue (eg: feature-co500). In general, feature branches are used when merging directly into develop is undesirable, perhaps because the feature is experimental. Features may also be used when a priority enhancement is made for a specific deployment, and the enhancement is required before the next scheduled minor release.
   1. Feature branches may also be used to target develop for a future (ie: not the next) feature release. In this case, the feature branch is named for the target release (eg: feature-3.1) rather than a JIRA issue.

Summary

References

• http://nvie.com/posts/a-successful-git-branching-model
• http://scottchacon.com/2011/08/31/github-flow.html