Re: Workflow Help

["Magnus Bäck" <baeck@google.com>]

On Monday, May 20, 2013 at 20:59 EDT,
     "Quilkey, Tony" <trq@thorpesystems.com> wrote:

> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
> 
> Our basic workflow will be based around:
> http://nvie.com/posts/a-successful-git-branching-model, with a few
> exceptions.
> 
> We would like to create our release-* branches from the last release
> tag. From there, we would like the ability to cherry pick (or take the
> complete diff) commits from the develop branch.

It would probably be easier to comment on your proposal if you motivated
why you want to diverge.

> So, we are after is:
> 
> 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.

The point of having a release branch is typically to slow down the
development pace and reduce risk by only adding changes that you
really need. By starting the branch for release N+1 from the branch
for release N it seems you have three ways forward:

   - Cherrypick a small number of commits from develop. That'll give you
     release N+0.1 rather than N+1.
   - Cherrypick many (if not most) commits from develop. That might give
     you a real release, but with a lot of work. Who should select which
     commits to cherrypick? How do you keep track of dependencies? Why
     would you want to move from a known state (develop, where people
     spend most of their time) to an unknown state?
   - Merge from develop to the release branch. What's the benefit
     compared to cutting the release branch directly from develop?

As another poster has pointed out, with merging instead of cherrypicking
the standard Git tools will be able to do a better job at helping you
track which corrections are made where.

[...]

-- 
Magnus Bäck
baeck@google.com