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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html