gitflow hot fix分支vs長期發布分支

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-SNAPSHOT。 發布時，我會創建1.0.0的發布版本，將其標記並合並為master。 現在，而不是刪除發行分支，我將版本增加到1.0.1-SNAPSHOT。 這實際上成為1.0.x版本的長期熱修復分支。 如果發現生產中的錯誤，則將其修復在該分支上，剪切1.0.1發行版本，並將版本增加到1.0.2-SNAPSHOT，依此類推。

缺點是只要此發行版是當前發行版，發行分支就存在。 好處是，如果存在錯誤，並且分支已經存在，則不需要創建新的熱修復分支。

因此，我的問題是是否沒有熱修補程序分支並以這種方式進行操作，從而錯過了任何主要問題？

Answer 1

我們在工作中采用了nvie模型，並且效果很好。

該修補程序僅用於發行軟件的較小補丁-在合並到母版和刪除它們之前，其生存期非常短。 同時，develop分支用於進行重大改進的工作。

我對nvie模型看到的（次要）優勢是修補程序分支的壽命很短。 在一個團隊中，我可以看到為需要的人准備的修補程序分支的好處。