Proper handling of merging between branches

Martin Pool mbp at canonical.com
Tue Oct 12 04:19:57 BST 2010


I think the approach there is basically reasonable.

Some other variations:

 * after you do a 'major release' when everything from trunk is merged
into staging, then pull staging back to trunk; that way trunk never
goes very far away or develops its own ancestry
 * cherrypick the change into trunk, so that you bring across only the
critical fix, and nothing else
 * get rid of trunk as a branch in its own right and just have feature
branches that merge into staging when they're stable (or perhaps this
is better said as, have only a trunk that stays deployable)

It's funny you should mention Launchpad as an example because they're
in the process of moving away from having a separate edge branch, see
eg <https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone>
<https://dev.launchpad.net/MergeWorkflow> and recent posts to
<http://lists.launchpad.net/launchpad-dev>.

-- 
Martin



More information about the bazaar mailing list