Multiple development branches with git-flow

git version-control git-flow branching-strategy

13,231

Solution 1

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.

Solution 2

Solution 3

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.

13,231

LiKao

C++ Programmer with a strong background in audio processing and music information retrieval. Strong interest in functional programming and programming languages in general. My Github page: https://github.com/LiKao

Updated on June 06, 2022

Comments

LiKao almost 2 years
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?
- atian25 over 11 years
  
  hi, is this feature supported by git-flow now?
- Adam Dymitruk over 11 years
  
  google "Branch per Feature". There has been a backlash against this from the CI crowd - specifically subversion advocates. My article is an argument for it given the right tooling. Hope it helps people understand the crux of the issue - especially the link to the discussion - no need for a google+ account to read it. It is copied into a separate page on my site.
LiKao over 12 years

Ok, bad wording on my side. I should not have used the word "possible" but more something like "easily supported by". Let me see if I understand your answer correctly: If I do a git flow feature start this feature is branched of the current position? I.e. if I am on master it will be branched from there? Because the tutorials I watched gave the impression it would be branched from develop no matter what is currently checked out. I guess then the only issue would be keeping master in correct states (for example when 1.1 is released after 2.0).
user229044 over 12 years

If you do git flow feature start you're already lost, because git-flow fundamentally does not support what you're doing. You'll have to use git, not git-flow to achieve what you want. Checkout your 1.0 branch, and git checkout -b feature/my-feature. You'll have a new branch using 1.0 as a starting point.
LiKao over 12 years

Ok, I see. I thought there was a way to handle this directly in git-flow. Somehow I guesses this was a common feature with multiple customers requesting different features, so it might have been present somehow in git-flow directly. Seems it's not so common after all. I guess I have to think some more on how to adapt the git-flow workflow to our use-case.
drudru about 12 years

i cannot get to google plus without creating an account and agreeing to forms. is there a copy of this on a blog?
drudru about 12 years

@meagar you should make the commands part of your main answer
user229044 about 12 years

@drudru You don't have to have an account to view that link.
michael almost 12 years

" I do not need any tips on git alone, but directly on the workflow with git-flow." -> "me too". This question as of yet seems unanswered (there may not be an answer w/o a git-flow enhancement).
user229044 almost 12 years

@michael_n Git-flow is first and foremost a series of best-practices. The somewhat gimpy command-line tool is not required to adhere to these best practices, and indeed in many instances, like the one discussed in the question, it hinders more than it helps. My answer addresses how to use Git-flow, not specific commands (which don't exist) to use on the git-flow CLI.
michael almost 12 years

@meagar "first and foremost a series of best-practices" I don't think anyone would disagree, but it's half the story. It's also (by definition) "a collection of Git extensions to provide high-level repository operations.." Extensions, i.e. real software. There are tomes on git, we know it can slice, dice, julienne. But every git-flow Q on SO can't be resolved with "don't know, doesn't matter, see git". A better answer is "you can't do that and still reasonably use git-flow" or "steps to use git-flow with git, w/o totally screwing the pooch: 1,2,3,..."
user229044 almost 12 years

@michael_n I would disagree, as the git-flow Git extensions are so limited in their implementation that they are essentially useless for non-trivial projects.
michael almost 12 years

@meagar - actually that's a very good answer to the original question.