What is a "Support Branch"?

21331 views
Skip to first unread message

Von

unread,
Aug 19, 2010, 6:58:21 PM8/19/10
to gitflow-users
gitflow (0.2) seems to have something called a "support branch" ('git
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

unread,
Aug 19, 2010, 10:50:58 PM8/19/10
to gitflow-users
I, too, was wondering about this. I'm not sure if the implementation
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

unread,
Aug 19, 2010, 11:18:24 PM8/19/10
to gitflo...@googlegroups.com
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
--
True software development embraces consistent inconsistency.
blog: http://codeslife.com

justin

unread,
Aug 20, 2010, 8:25:57 AM8/20/10
to gitflo...@googlegroups.com
When you run `git flow support help`:

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

unread,
Aug 21, 2010, 12:37:52 PM8/21/10
to gitflow-users
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
> justinhttp://justinhileman.com
>
>
>
> 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

unread,
Apr 10, 2012, 5:27:09 AM4/10/12
to gitflo...@googlegroups.com
On Saturday, August 21, 2010 6:37:52 PM UTC+2, Von wrote:
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

I am now on git-flow 0.4.2-pre according to git flow version. However, this message is still there and I cannot see any updates on http://nvie.com about this feature becoming stable. Is it safe to use support branches now?

--
Jurian Sluiman

alpo...@googlemail.com

unread,
Jul 3, 2012, 3:32:35 PM7/3/12
to gitflo...@googlegroups.com
+1

I'd like to know that too. Are support branches still experimental?

liuy...@gmail.com

unread,
Oct 30, 2012, 10:53:00 PM10/30/12
to gitflo...@googlegroups.com, alpo...@googlemail.com
+1 for this.

在 2012年7月4日星期三UTC+8上午3时32分35秒,alpo...@googlemail.com写道:

天猪 蓝虫.

unread,
Oct 30, 2012, 11:32:39 PM10/30/12
to gitflo...@googlegroups.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

unread,
Nov 4, 2012, 9:15:51 PM11/4/12
to gitflo...@googlegroups.com
On Tuesday, October 30, 2012 11:32:39 PM UTC-4, 天猪 蓝虫. wrote:

> 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


Giving a base doesn't change the finish flow, it always is master. I guess it could be solved by adding some code that would remember the base a hotfix was based from but that's another topic.

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.
 
--
Peter van der Does
Maintainer of git-flow (AVH Edition)

git-flow (AVH Edition) is located on github:
  Repository: http://goo.gl/9hGZ3
  Changelog: http://goo.gl/jpVJE

Any updates made to git-flow (AVH Edition) are almost impossible to make into easy pull requests for the original git-flow. The source code of my fork has diverged to much to make this an easy process and therefor we won't.

stanisla...@gmail.com

unread,
Jul 9, 2013, 1:37:50 PM7/9/13
to gitflo...@googlegroups.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
Reply all
Reply to author
Forward
0 new messages