在git-flow之后你应该如何处理早期版本的修补程序？

Question

如果您尝试按照混帐流分支模型,记录在这里,并与这里的工具,你应该如何处理这种情况:

您已经发布了1.0版本和2.0版本.然后你需要为1.0创建一个修补程序.您从1.0标记创建一个修补程序分支,并在那里实现修复.那么呢？

通常,您将合并为master并在其中放置1.1版本标记.但是你不能将1.1合并到主控之后的2.0之后.

我猜你可以把release标签放在hotfix分支上,但是这会在master上创建一个包含release标签的永久分支.这是正确的方法吗？

Answer 1

似乎git流中有一个"支持"分支的概念.这用于向早期版本添加修补程序.

这个帖子有更多的信息,这些例子如下:

git checkout 6.0
git checkout -b support/6.x
git checkout -b hotfix/6.0.1

...进行修复,然后:

git checkout support/6.x
git merge hotfix/6.0.1
git branch -d hotfix/6.0.1
git tag 6.0.1

或使用 git flow命令

git flow support start 6.x 6.0
git flow hotfix start 6.0.1 support/6.x

......然后做出改变:

git flow hotfix finish 6.0.1

Answer 2

有趣的问题!您链接的流程假定master可以跟踪生产.这仅适用于生产版本严格增加的情况.对于只有一个生产版本的网站来说,这通常是正确的.

如果您必须维护多个生产版本,那么一个跟踪生产的分支是不够的.解决方案不是使用master来跟踪生产.相反,使用状分枝release1,release2等等.

在这种方法中,您甚至可能不需要修补程序分支.你可以修复release1分支上的问题.当修复程序足够好时,release1.1在release1分支上创建一个标记.

Answer 3

git-flow假设您一次只支持一个释放线,由主人方便地跟踪.如果您维护的数量超过1,那么您将需要修改git-flow进程以使您支持的单独版本的多个跟踪器(master-1,master-2).您可以继续使用master来跟踪最新的版本行,除了或代替最新版本行的特定跟踪器(master代替master-2).

不幸的是,您可能正在使用的任何git-flow工具都可能需要修改,但希望您对git-flow进程非常熟悉,可以直接使用git命令处理这个特定情况.