>  Or course, it's perfectly sensible to
> merge back to a "common" branch any bugfixes pertaining to it, but I
> can't get such "accumulate and apply all at once" approach. It seems
> like a quite contrived approach, whch is invented just because it
> could be invented, and not from a real need.

My company is moving to git soon, and I think we will need a workflow
kind of like this to support our multi-product build process with
point releases.  Here's what we're thinking; I'd appreciate the input
from the group on it.

We have a single code base, from which we produce several products
(prodA, prodB, etc).  The code is mostly common, but some is specific
to prodA, some to prodB.  The idea is that the 2010 releases of all
these products starts out from the same trunk, but as each one is
released it goes onto its own release branch (for 2010.1, 2010.2, etc.
releases).  Now the question is how to handle bug fixes; we want the
bug fixes to go into whatever releases need them (and only those -- to
avoid destabilizing the others), but also merge back to trunk for the
2011 development that's ongoing.

Our current plan is to have trunk, release_prodA, release_prodB, and
release_common branches.  If you have a bug fix for prodA, you go to
its release branch, make the fix and test it there, commit it, and
then merge to trunk.  If you have a bug fix that applies to >1
product, you go to one of the release branches (release_prodA for
instance), make the fix and test it, but then apply the fix on
release_common.  Then merge from release_common to all the other
release branches, and to the trunk.  This way everyone gets the common
fixes, and the specific product fixes don't pollute the other

Does that seem like a decent workflow?

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to