I am currently looking a lot into git-flow, and trying to figure out, how to use it for the projects I am involved on.
I have looked at the various git-flow tutorials and I am fairly familiar with git. Hence I do not need any tips on git alone, but directly on the workflow with git-flow.
Here is the situation:
When I relase a version (let's call it 1.0), this get's branched of develop, which is fine. Let's say now I start working on 2.0, adding new features. And of course I want to merge them back onto develop, once I am done. Now hotfixing on 1.0 is fine, so let's also say I produce several versions 1.0.1, 1.0.2 etc. All these will also update the develop branch, which is also nice. So far now hassle, I can develop features for 2.0 and hotfixes for 1.0.x independtly.
However let's say someone requests a new feature for a 1.1 release. Now I have a problem. If I create a feature branch, this will be based upon the develop branch, which might already contain 2.0 stuff, which I might not want in this 1.1 release.
Is there a simple way, to handle these 2.0 and 1.1 changes independtly?
There are several possibilities I see already:
create a new branch at the last release position on develop. Rebase the develop onto this position and rename the other develop branch. However then this branch would not contain any hotfixes from 1.0.1 etc.
Do not merge back features for 2.0 before 2.0 is done. However then I would have to leave a lot of unmerged changes open until the last moment. Also this does not help, if 2.0 get's released and afterwards changes to 1.0.x are requested.
Is this possible at all with git flow? I.e. basing releases upon an earlier release once the work for a newer release has been started or even finished?
Is this possible at all with git flow?
Anything is possible using git-flow as a series of best-practices rather than a hard rule. Just open your feature branches from your 1.0
release branch instead of from your develop
branch.
More on "git-flow improved":
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
The key is to start features from the point of last release. Whether you have 1 or more supported versions that are published should not be an issue.
UPDATE:
I have it rewritten - in blog form:
I realize this is an old question, but I just found a fairly simple way of handling it on my end.
On my development server I basically have two working copies, one for v1.0 and another for v2.0.
I then create a separate "develop" branch for v2.0, and when I run "git flow init" on the 2.0 environment, I use this as my "next release" branch.
I am sure you could do the same for the master branch, but for my purposes this was sufficient.
I believe if you want to support two versions of app at the same time it will be better to create two different repositories for that.
来源:https://stackoverflow.com/questions/8579056/multiple-development-branches-with-git-flow