我一直在关注gitflow工作流程http://nvie.com/posts/a-successful-git-branching-model/，这很有意义，与我过去的做法非常相似。在发布和热修复方面，我做的事情有点不同，想要询问gitflow分支与我提出的方式相比的优缺点。
通常当我创建一个发布分支时，比如发布1.0.0，我将命名发布分支发行版1.0.0，而不是发行版1.0.0。一旦我创建了分支（但在代码发布之前），对于任何最后一分钟的修复，版本将是1.0.0-SNAPSHOT。当我发布时，我创建1.0.0的发布版本，标记它并合并到master。现在，不是删除发布分支，而是将版本增加到1.0.1-SNAPSHOT。这有效地成为1.0.x系列版本的长期热修复分支。如果我在生产中发现了一个错误，我会在这个分支上修复它，剪切一个1.0.1版本并将版本增加到1.0.2-SNAPSHOT，依此类推。
缺点是只要此版本是当前版本，就会存在版本分支。好处是，如果有错误，我不需要创建新的热修复分支，并且分支已经存在。
所以我的问题是，由于没有热修复分支并且这样做，我错过了任何重大问题吗？
答案 0 :(得分：1)
我们在工作中采用了nvie模型，效果非常好。
此修补程序仅用于已发布软件的次要修补程序 - 并且在将它们合并到主控并删除之前将具有非常短的生命周期。同时，开发分支用于实现重大改进。
我看到nvie模型的（次要）优势是修补程序分支的短暂活动。在一个团队中，我可以看到如果需要，可以使用修补程序分支的优势。