gitflow热修复分支与长期版本分支

Question

我一直在研究gitflow工作流程，有点http://nvie.com/posts/a-successful-git-branching-model/，它很有意义，非常类似于我过去所做的事情。当涉及到发布和热修复时，我做的事情有点不同，我想问一下他们的gitflow分支方式与我提出的方式的优缺点。

通常，当我创建一个发布分支时，比如版本1.0.0，我会将发布分支命名为release-1.0.x，而不是release-1.0.0。一旦我创建了分支(但在代码发布之前)，版本将是1.0.0-快照，用于任何最后的修复。当我发布时，我创建了1.0.0的发布版本，标记它并合并到master。现在，我没有删除release分支，而是将版本增加到1.0.1-SNAPSHOT。这实际上成为了版本1.0.x系列的一个长期热修复分支。如果我在生产中发现一个bug，我会在这个分支上修复它，削减1.0.1发布版本，并将版本增加到1.0.2-SNAPSHOT，依此类推。

缺点是，只要此版本是当前版本，发布分支就会一直存在。好处是，如果有bug，并且分支已经存在，我不需要创建新的热修复分支。

因此，我的问题是，如果不使用热修复分支并采用这种方式，我是否会遗漏任何重大问题？

Answer 1

我们已经在工作中采用了nvie模型，它工作得很好。

该修补程序仅用于已发布软件的次要修补程序-在将它们合并到主要修补程序和删除它们之前，修补程序的生命周期非常短。同时，开发分支用于主要改进的工作。

我看到的nvie模型的(次要)优势是hotfix分支的生命周期很短。在一个团队中，我可以看到有一个热修复分支的好处，以供他们在需要时使用。