tags:

views:

80

answers:

2

I was using the rebasing topic branches workflow http://www.golden-gryphon.com/software/misc/packaging.html

But because the local testers and admins don't like throwaway release branches, I need to move to a worklow with stable branches.

The only one that is acceptable is merging workflow. Now the issue is that I don't know how to work with dependent feature branches in this workflow. When rebasing, this was simple, with each patch I simply rebased all the feature branches that depended on this branch and everything was back to normal. With the merging workflow I can't rebase my feature branches, but merging seems a bit crazy for this.

Is there some better approach?

+2  A: 

The main difference between a merge and a rebase workflow is that merges are invisible in the rebase workflow, but they still happen (you can see them in the reflog after the rebase). There are even much more of then using rebase, since for every new changeset of the to be rebased branch a merge of its own is performed, while in the plain merge workflow only one merge between the two branch heads are done.

A typical merge workflow looks like this:

             o-o-o--------------o         Release1+bugfixes
            /     \              \
o-----o----o--o-o--o---o----o-o-o-o-o--o  develop
       \     /               \     /
        o-o-o Feature 1       o---o Feature 2

Short-term features are developed in develop, long-term features get their own branches. Feature branches gets merged back into develop. For every release a branch is created from develop, and bugfixes are created on the release branch where the bug appeared. When a bugfix is done, it is merged back into develop.

A better explanation can be found at http://nvie.com/posts/a-successful-git-branching-model/.

Rudi
The problem is that I have several inter-dependent long-term feature branches. The workflow you describe is trivial (and pretty much part of my larger workflow).
Let_Me_Be