The COmanage Project has adopted a modified version of git-flow as its branch management strategy. In short, the differences are
hotfix-1.0.x
is used for (eg) 1.0.1
and1.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.develop
, which eventually merges into master
to create a release tag.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.feature-3.1
) rather than a JIRA issue.Do not commit the same change to multiple branches. Pick the "earliest" relevant branch and commit there. For example, if you commit to hotfix-3.0.x, do not also commit to develop. Your commit will flow to develop at the next merge. This makes it easier to track where a change came from. Under limited circumstances, it may be necessary to cherry pick a commit or otherwise violate this rule. Please discuss before doing so. |
Branch | Description | Branches From | Merges To |
---|---|---|---|
master | Current release or release candidate | - | - |
develop | New features scheduled for next minor release | - | master , hotfix-* (if appropriate) |
hotfix-* | Bug fixes and minor changes scheduled for next bugfix release | master | master , develop |
feature-* | Experimental or prioritized features | master for prioritized development, otherwise any suitable branch | develop , hotfix-* (if appropriate) |