> 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 products. 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
