On Tue, Jul 21, 2009 at 5:29 PM, Tekkub<[email protected]> wrote: > Peter, assuming that > the release branch and master have some common point where they branched from (which, ideally, is a tag for the x.0.0 version of the release)... this is how I would do the bugfixes: > * Branch at the tag/common point > * Fix the bug > * Merge that branch into both the release branch and the master branch.
Sounds like a good workflow and one we'd not thought of. > The problem with both cherry-pick and rebase is you'll end up with two commits. If you have a lot of bugfixes, it could > quickly become a headache to track which have been merged into both branches. Yes. We noticed. ;-) >The version.h files wouldn't run into any conflict unless you're editing them in the bugfix commits, which you probably shouldn't be Right; we don't. We update version.h only for "official builds", which we track only in the public branches. > In short, don't work directly in master or the release branches, aside from > changing your version.h files. Work in topic branches at all times, and > merge them into the master/release branch when the topic branch is tested > and ready to be integrated into one of those releases. Right. Even my workflow did this, but your idea of initiating the bugfix branch at the common ancestor of the master and release branch is better than what I had. Unfortunately, we sometimes have to maintain 3 simultaneous branches, but even in this case, starting the bugfix branch from the older of the two branch points should still work. Thanks, -P. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "GitHub" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/github?hl=en -~----------~----~----~----~------~----~------~--~---
