Intro
It is important to follow a particular pattern when keeping release maintenance branches and integration branches up to date.
Glossary
- 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.
Procedure
In preparation for a release, a release maintenance branch is 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 master. 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 changes on the release maintenance branch and merge into master anyway, then "git revert" or manually back out the changes on master.
Never merge from master to the release maintenance branch
This is likely to pull in changes for future releases that should not be part of the imminent release.
Whoops, I committed to master first!
If you accidentally commit something to master first that also should be in the release maintenance branch, just cherry pick it from master. Future "git merges" from the release maintenance branch to master will do the right thing.
Whenever you "git cherry-pick", please use the "-x" argument so the original (source) commit is mentioned in the new commit.
See also
- Specific examples of release branch merging policies