Re: Workflow Help

From: Magnus Bäck <baeck@google.com>
Date: May 21, 2013, 13:07 UTC
Message-ID: <20130521130748.GA634@google.com>
In-Reply-To: <CAMATmi3bU7hrD-YLY1iVXbekxOx_XZfZ5yYNBfzV_VFSc_W5jw@mail.gmail.com>

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

Show 11 quoted lines

> 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.

Show 10 quoted lines

> 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