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