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
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
> 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.
> 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
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.