Git workflow: Managing topic branches.

Git workflow: Managing topic branches.

[Thomas Adam]

Hello all,

I've a question regarding a specific workflow which we're currently using
here at work, but I am not convinced it's particularly brilliant -- and
there's a number of oddities about it which I'd like to discus -- perhaps
with a way of coming up with a new solution.

We have a work-flow such as this:


         o---o---o---o--o--o (stable)
        /
o---o---o---o---o---o---o  (master)
     \
      o---o--o---o---o---o (featureA)


Master is where all our stable code lives after a release -- and also where
bug-fixes for released code is put.  When we're working on a new feature,
almost all developers here will push (in this case) to "featureA" ---
eventually this branch will get merged into master, tagged and the code
released.  Then a new branch, "featureB" is created off it, and process
continues.  (Yes, we're using Git in a very CVS-like way, alas.)

Periodically though we need to release updates for our product.  This the
area which is where my question lies about whether the workflow is good or
not.  Here's how we do that:

We have a branch called "stable" which contains all of our released code
plus any updates release.  When we wish to create a new update, we create a
new branch off the tip of stable:


                            o---o---o---o (updateN)
                           /
         o---o---o---o--o--o (stable)
        /
o---o---o---o---o---o---o  (master)
     \
      o---o--o---o---o---o (featureA)


Because bug-fixes happen on Master, we now want those fixes to appear on the
updateN branch so we can create a tarball from them (to release to our
customers).  We're using "git cherry" to get a list of SHA1s that are
relevant between updateN and master, as in:

git cherry updateN master

... and then manually deciding (based on it's "+"/"-" output whether that
SHA1 needs to be used and then:

git cherry-pick SHA1

... onto updateN as appropriate.  This branch is then pushed to our
"central" server as a public branch, is checked out elsewhere on another
macine to build this update.  If that's successful, various other bits and
bobs in terms of meta data is added into the commits onto the updateN branch
and it is merged into stable:

                            o---o---o---o (updateN)
                           /            / <-- (merge updateN to stable)
         o---o---o---o--o--o------------o (stable)
        /
o---o---o---o---o---o---o  (master)
     \
      o---o--o---o---o---o (featureA)

The "stable" branch is then merged into master so that when we create
another "featureX" branch, it's at a point where it's on a known set of
released code.

So my questions:  I am not convinced this workflow is very elegant, or
indeed a particularly good solution to what we're wanting to do.  Because
the cherry-picking that happens to the "updateN" branch happens from
"master" which itself will have had several local topic-branches merged into
it from other developers -- I've found "git-cherry" to give unreliable
results -- in some cases, the same two commits with the same data appear on
the "updateN" branch -- using git patch-id manually with processing on top
of that seems to give a much shorter and succient set of SHA1s to
cherry-pick.  (But this is kind of peripheral to my question).

I am interested to know if this branch and merge scenario is the right one.
I also don't believe we're using git-cherry in the right way to isolate the
correct commits.  I have toyed with the idea of rebasing, but am hesitant on
this idea, and unsure if that would even be the right way to go --
especially seeing as all the branches mentioned are tracking branches.

The eventual aim of all of this is to try and automate building of these
updates -- but we sure as hell can't do that at the moment with our current
workflow.  If anyone has any suggestions on any of this, I'd appreciate it.
If I've not explained things adequately. shout and I'll try and clarify.

Thanks in advance,

Thomas Adam

Re: Git workflow: Managing topic branches.

[Johannes Sixt]

Thomas Adam schrieb:
> We have a work-flow such as this:
> 
> 
>          o---o---o---o--o--o (stable)
>         /
> o---o---o---o---o---o---o  (master)
>      \
>       o---o--o---o---o---o (featureA)
> 
> 
> Master is where all our stable code lives after a release -- and also where
> bug-fixes for released code is put.  When we're working on a new feature,
> almost all developers here will push (in this case) to "featureA" ---
> eventually this branch will get merged into master, tagged and the code
> released.  Then a new branch, "featureB" is created off it, and process
> continues.  (Yes, we're using Git in a very CVS-like way, alas.)
> 
> Periodically though we need to release updates for our product.  This the
> area which is where my question lies about whether the workflow is good or
> not.  Here's how we do that:
> 
> We have a branch called "stable" which contains all of our released code
> plus any updates release.  When we wish to create a new update, we create a
> new branch off the tip of stable:
> 
> 
>                             o---o---o---o (updateN)
>                            /
>          o---o---o---o--o--o (stable)
>         /
> o---o---o---o---o---o---o  (master)
>      \
>       o---o--o---o---o---o (featureA)
> 
> 
> Because bug-fixes happen on Master, we now want those fixes to appear on the
> updateN branch so we can create a tarball from them (to release to our
> customers).  We're using "git cherry" to get a list of SHA1s that are
> relevant between updateN and master, as in:
> 
> git cherry updateN master
> 
> ... and then manually deciding (based on it's "+"/"-" output whether that
> SHA1 needs to be used and then:
> 
> git cherry-pick SHA1
> 
> ... onto updateN as appropriate.

Your workflow looks quite reasonable except for this last part. You should
make your history look like this:

          o--o--o--o--o         stable
         /       \     \
--o--B--o--o--o---o--o--o--o    master
      \
       o--o--o--o--o--o         featureA

Instead of cherry-picking commits onto updateN (or stable), your
developers should think which branches need the change that they are about
to commit. If it is a serious bug-fix, then it should be enter the picture
on stable, not on master or feature branches. The important part is that
branch stable is merged into branch master (at least after each release,
but perhaps even more often).

Now assume that your developer discovers a bug while she was developing on
featureA that must go into stable. Previously you would have done it this
way (I presume):

--o--B--o--o--o---o--o--o--o--o    master
     |   \       /     /     /
     |    o--o--o--o--o-----F'     stable
      \
       o--o--o--o--o--o--F         featureA

That is, the fix F was committed on the feature branch and later was
cherry-picked onto stable as F' and then merged into master. But she
should have done this instead:

--o--B--o--o--o---o--o--o--o--o    master
     |   \       /     /     /
     |    o--o--o--o--o-----o      stable
     |\                    /
     | F------------------<        fixF
      \                    \
       o--o--o--o--o--o-----o      featureA

That is, fix F should go on its own bugfix-branch and that branch is
merged into stable as well as into featureA (but only if the fix is really
needed there); stable is in turn merged into master again. The new branch
grows from a commit that is in common to all the branches that need the
fix. Since the fix is needed on featureA as well as on stable, the lastest
possible branch point is B (where feature A was branch off of master/stable).

Side note: An even better branch point would be the commit that introduced
the bug, which must have been B or a commit before it; otherwise the bug
would not have shown up during the development of featureA. This way you
could make the decision anytime later whether you want to merge the fix
into older releases as well.

-- Hannes