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模型的（次要）優勢是修補程序分支的短活躍區域。在一羣人中，我可以看到有一個修補程序分支隨時可供使用的優勢，如果需要的話。