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.

Sounds fine.

> 2) Once it is decided we are packaging a release, make a release-*
> branch from the previous release tag.

Sounds fine.

> 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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to