Login/Register
Multiple development branches with git-flow
Asked Answered
Solved gitversion-controlgit-flowbranching-strategy
S

4

22

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?

Snip answered 20/12, 2011 at 16:59 Comment(2)
hi, is this feature supported by git-flow now? – Intercellular
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. – Nagpur
G
4

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.

Glare answered 20/12, 2011 at 19:56 Comment(9)
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). – Snip
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. – Glare
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. – Snip
@meagar you should make the commands part of your main answer – Narcotic
" 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). – Lovieloving
@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. – Glare
@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,..." – Lovieloving
@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. – Glare
@meagar - actually that's a very good answer to the original question. – Lovieloving
N
5

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:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Nagpur answered 20/12, 2011 at 20:7 Comment(4)
i cannot get to google plus without creating an account and agreeing to forms. is there a copy of this on a blog? – Narcotic
@Narcotic You don't have to have an account to view that link. – Glare
git flow feature finish <name> keeps trying to merge with develop branch instead of the base branch it works on – Lactone
plus.google link is deat it gives Google+ is no longer available for consumer error – Lactone
G
4

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.

Glare answered 20/12, 2011 at 19:56 Comment(9)
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). – Snip
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. – Glare
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. – Snip
@meagar you should make the commands part of your main answer – Narcotic
" 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). – Lovieloving
@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. – Glare
@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,..." – Lovieloving
@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. – Glare
@meagar - actually that's a very good answer to the original question. – Lovieloving
G
1

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.

Garter answered 16/1, 2018 at 9:4 Comment(0)
A
0

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.

Antecede answered 4/12, 2015 at 15:35 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.