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