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