gitflow热修复分支vs长期发布分支

Question

我一直在寻找gitflow工作流程，它有道理，并且与我过去所做的非常相似。当涉及到发布和热修复时，我做了一些不同的事情，并想问一下他们的方式gitflow分支的优势和劣势，以及我提出的方式。

通常，当我创建发布分支时，比如发布1.0.0版本，我会将发布分支名称命名为1.0.x，而不是release-1.0.0。一旦我创建了分支（但在代码发布之前），对于任何最后一分钟修复，版本都将为1.0.0-SNAPSHOT。当我发布时，我创建了1.0.0的发布版本，对它进行标记并合并为主。现在，而不是删除发布分支，我将版本增加到1.0.1-SNAPSHOT。这实际上成为1.0.x系列发布版的一个长期修复热门分支。如果我发现生产中存在一个错误，我将在此分支上修复它，剪下1.0.1版本并将版本增加到1.0.2-SNAPSHOT，等等。

不利之处在于，只要此版本是当前版本，发布分支就存在。好处是我不需要创建新的修补程序分支，如果有错误，并且分支已经存在。

所以我的问题是我错过了这里没有热修复分支和这样做的任何重大问题？

Answer 1

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

此修补程序仅用于已发布软件的次要修补程序 - 并且在它们被合并为主程序和删除程序之前将具有很短的生命周期。同时开发分支用于重大改进的工作。

我看到的nvie模型的（次要）优势是修补程序分支的短活跃区域。在一群人中，我可以看到有一个修补程序分支随时可供使用的优势，如果需要的话。