On Tuesday, May 21, 2013 6:39:30 PM UTC-4, Tony Quilkey wrote:
> 1) Create topic (feature) branches from develop, and merge back into
> develop when complete.
> 2) Once it is decided we are packaging a release, make a release-*
> branch from the previous release tag.
> 3) Cherry pick/merge/whatever any commits we want from develop into
> the new release-* until it is complete.
Avoid cherry-pick. Prefer merge to help git manage history (`That commit
has already been applied on this release branch', or `You need to apply
commit A first to apply commit B') for you.
4) Merge the new release-* branch into master and tag it.
Alarm bells. The purpose of the release-* branch is to never be merged back
into master. The flip side of the coin is that you want every commit on
master to be good enough to create a new release from. I.e. only merge a
commit into master if you would be comfortable with deploying it.
Reading this and the rest of your posting (which I've cut out) I feel I
should clarify this: on a release-* branch you will be applying bugfixes
only. You won't be applying anything new that's done on the develop branch.
If you want to apply a bugfix to multiple release-* branches you find their
common ancestor (or even better, the old commit that introduced the bug),
fix it on top of that, and merge into the release-* and develop branches.
If all else fails, of course, you fall back on cherry-pick.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.