What is a "Support Branch"?
Von
flow support...').
But I don't see it mentioned on nvie.com or in other gitflow
documentation.
Out of curiosity, what is a support branch?
Thanks,
Von
terinjokes
in the v0.2 script is the same, but it likely comes from the same
idea.
Vincent makes a comment on the original blog post, located at
http://nvie.com/git-model#comment-185.
> * Create a “support branch” called support-1.x, based on tag 1.1 (since that is the latest 1.x commit). This branch should be long-lived and can be safely removed if you drop support on 1.x.
> * Create a branch hotfix-1.1.1, based on support-1.x
> * Create a branch hotfix-2.0.1, based on 2.0
> *Fix the bug on each (git cherry-pick may help here)
Hopefully someone with more knowledge about what it's actually doing
here can shed some light.
--
Terin Stock
Larry Cai
justin
note: The support subcommand is still very EXPERIMENTAL!
note: DO NOT use it in a production situation.
usage: git flow support [list] [-v]
git flow support start [-F] <version> <base>
So I prob'ly wouldn't use it just yet. But if you're interested:
As I understand it, support branches are similar to LTS version of
Linux distros.
Say you had a project, and you were happily releasing new versions.
Maybe your current production version was 8.x. But you had some Really
Important Customers who refused to upgrade to anything after 6.0. Now,
if someone found a security flaw in the 6.0 version of your project,
it would be a bad idea to hang all those Really Important Customers
out to dry. So you release a new hotfix against 6.0, even though all
their problems would be solved if they just upgraded to the new
release (It has been _nearly 10 years_ since you released 6.0 after
all).
In order to keep supporting these Really Lazy Customers, you release
hotfix 6.0.1 to fix the security bug. In "normal" git, it would look
something like:
> git checkout 6.0
> git checkout -b support/6.x
> git checkout -b hotfix/6.0.1
... make your fix, then:
> git checkout support/6.x
> git merge hotfix/6.0.1
> git branch -d hotfix/6.0.1
> git tag 6.0.1
... if needed, this change can also be applied to a hotfix for 8.x,
via cherry-pick.
You would keep the `support/6.x` version around as long as your Really
Important Customers still needed security fixes for 6.0, and would
make 6.x.x releases off this branch instead of production.
The exact same process using git-flow looks like this:
> git flow support start 6.x 6.0
> git flow hotfix start 6.0.1 support/6.x
... make changes then:
> git flow hotfix finish 6.0.1
Unlike a normal hotfix, a hotfix agains 6.x probably shouldn't be
merged into your current production and development branches, since
you are on version 8 already. I'm not sure `git flow hotfix finish` is
smart enough to know this yet, so that might be the reason for the
warning you get when you ask for `git flow support help` ...
I wouldn't use it yet, but it looks like it'll be a useful feature in
the future, especially for large projects which require legacy
support.
--
justin
http://justinhileman.com
Von
Thanks for taking the time to explain.
My summary is that its branches for releases other than the most
recent release but that still need to be supported, which I agree is
common and very useful.
Von
>
>
> On Thu, Aug 19, 2010 at 11:18 PM, Larry Cai <larry.ca...@gmail.com> wrote:
> > In his blog, except master and develop branch, all others are called
> > supporting branch.
> > And typical supporting branches are
> > - feature branch
> > - release branch
> > - hotfix branch
> > In comments, support branch means the extra branch for hotfix for different
> > release and avoid to merge it back at once.
> > Is it correct ?
> > rgs/larry
Jurian Sluiman
Justin,
Thanks for taking the time to explain.
My summary is that its branches for releases other than the most
recent release but that still need to be supported, which I agree is
common and very useful.
Von
alpo...@googlemail.com
liuy...@gmail.com
天猪 蓝虫.
> git flow hotfix start 6.0.1 support/6.x
... make changes then:
> git flow hotfix finish 6.0.1
it seems that when finish, it will merge into master.
在 2010年8月20日星期五UTC+8下午8时25分57秒，justin写道：
Peter van der Does
> git flow hotfix start 6.0.1 support/6.x
... make changes then:
> git flow hotfix finish 6.0.1
it seems that when finish, it will merge into master
stanisla...@gmail.com
On Monday, November 5, 2012 3:15:51 AM UTC+1, Peter van der Does wrote:
My question is the following:What is that you want to accomplish by merging the hotfix into the support branch?I'm trying to get an idea what your thought process is.In general what are peoples ideas of the Support Branches? What do you think they are, I don't have a clue what the meaning is for them or how do would fit in with the original branches model but that doesn't mean they should be abandoned.
The idea as I understand it (and as I'd need it for our products) is basically that the premise of "releasing a new production version makes hotfixes for old ones unnecessary" is a false one. In praxis there is a need to support previous production versions older than the last one. Justin described the use case pretty good.
My unsorted ideas:
- a support branch starts from a commit in the master
- it lives "forever" - i.e. no finish
- a hotfix can be started from master or from a support branch
- when finising a hotfix gets applied to where it was started from
- a hotfix applied to a support branch should _not_ be automatically merged into develop. At that time it is quite possible that the branches diverged significantly and/or that the support branch only gets some quick band-aid while the develop contains a proper implementation.
- this is also something to consider for a hotfix applied to master - I do not necessarily want to apply it to develop