...
It is important to follow a particular pattern when keeping release maintenance branches and integration branches up to date.
...
- integration branch - In Mifos land, this is the "master" branch in the head git repo at sf.net. All bleeding-edge development code is integrated and tested on this branch.
- release maintenance branch - Releases are sometimes augmented by minor updates (bugfixes, etc.) while excluding new features and non-critical bugfixes. These types of changes are recorded on a branch separate from other integration branches.
- release engineering branch - A release-specific branch for changes for change that must be in the release, but must not be in future releases (ie: hard-coding the release name in application/pom.xml).
Procedure
In preparation for a release, a release maintenance branch is branches are created.
Changes for the imminent release and future releases
Commit to the release maintenance branch, merge to master.
Changes only for the imminent release
Sometimes we have changes to commit to a release maintenance branch that cannot be on masterin future releases. For example, the release version in a text file, or a manifest for a release zip. If the release maintenance branch and master haven't diverged too far and we're still merging, make the Make these changes on the release maintenance branch and merge into master anyway, then "git revert" or manually back out the changes on engineering branch. This branch will never be merged to master.
Never merge from master to the release
...
branches
This is likely to pull in changes for future releases that should not be part of the imminent release.
...
If you accidentally commit something to master first that also should be in the release maintenance branchbranches, just cherry pick it from master. Future merges from the release maintenance branch to master will do the right thing.
Whenever you "git cherry-pick" between two publicly visible branches (like master and g-maint), please use the "-x" argument so the original (source) commit is mentioned in the new commit.
...
Inspiration for separating release maintenance and release engineering: