Git - 上游+功能分支+发布分支

Question

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?

Answer 1

With several long-term features, the model might look like this:

     o-----o  bugfix
    /       \
o--o--o------o------o  develop branch
       \      \      \
        o-o----o---o--o  long-term feature 1
           \    \   \  \
            o--o-o-o-o--o--o feature 2

Basically, you have a development branch, and merge bugfixes to you development branch. Long-term feature branch is base of development branch, and you update it by merging new changes from that development branch.

Similarly, you have a feature branch for reature 2, base on feature 1, and you update it by merging new stuff new feature 1 branch.

When feature 1 is done, you merge it back to develop, and update feature 2 from develop branch:

     o-----o  bugfix
    /       \
o--o--o------o------o---o---o  develop branch w/ feature 1
       \      \      \ /     \
        o-o----o---o--o       \
           \    \   \  \       \
            o--o-o-o-o--o--o--o-o feature 2

Answer 2

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