LiK*_*Kao 21 git version-control git-flow branching-strategy
我目前正在寻找git-flow,并试图弄清楚如何将它用于我参与的项目.
我查看了各种git-flow教程,我对git非常熟悉.因此,我不需要任何关于git的技巧,而是直接使用git-flow的工作流程.
情况如下:
当我重新定义一个版本(让我们称之为1.0)时,这就得到了开发的分支,这很好.现在让我说我开始研究2.0,添加新功能.当然,一旦完成,我想将它们合并到开发中.现在1.0上的修复很好,所以我们也说我生成了几个版本1.0.1,1.0.2等.所有这些也将更新开发分支,这也很好.到目前为止,麻烦,我可以独立开发2.0和1.0.x的修补程序的功能.
但是,假设某人要求1.1版本的新功能.现在我有一个问题.如果我创建一个功能分支,这将基于开发分支,它可能已经包含2.0内容,我可能不希望在1.1版本中.
有一种简单的方法,可以独立处理这些2.0和1.1的变化吗？
我已经看到了几种可能性:
在开发的最后发布位置创建一个新分支.将开发重新定位到此位置并重命名另一个开发分支.但是,此分支不包含1.0.1等的任何修补程序.
在2.0完成之前,不要合并2.0的功能.然而,在最后一刻,我将不得不将大量未合并的更改保持打开状态.如果2.0发布并且之后要求更改为1.0.x,这也无济于事.
这对git flow来说有可能吗？即,一旦新版本的工作开始甚至完成,早期版本的版本是基于什么？
更多关于"git-flow改进":
https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR
关键是从上次发布的角度开始功能.是否有一个或多个已发布的受支持版本应该不是问题.
更新:
我重写了它 - 以博客形式:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
这对于 git flow 来说是可能的吗？
使用 git-flow 作为一系列最佳实践而不是硬性规则，一切皆有可能。1.0只需从发布分支而不是从分支打开功能分支即可develop。