跟踪发布，分支或标签？

Question

如何跟踪您的发布？

目前，我们有2个主要分支

• dev的
• 释放

几个人正在进行的开发总是发生在dev。完成足够的更改后，代码将合并到release中，并从中构建并在其中进行标记。然后部署代码。

问题：这种方法很好，但是经常出现新的错误，这些错误目前在开发分支中处理，它已经移动了（有时很多）。一旦问题得到解决，出现给客户的新构建通常包含修复和一些新功能。

我想将流程更改为以下内容：

• 当前＆lt; - 当前开发者流，最新和最强，尚未部署
• prod＆lt; - 目前正在prod，从dev / 1.0.2
合并
• dev / 1.0.0＆lt; - 不久前建造并交付给prod
• dev / 1.0.1＆lt; - 修复以前的构建，构建并交付给prod
• dev / 1.0.2＆lt; - 修复以前的版本，构建并交付给prod。 目前处于刺激状态

你怎么看？这种趋势是否会起作用并且长期可持续？我们确实每年发布约15次，每次发布至少有2-3次需要修复的产后事故，所以粗略地说，我们每年将有75个分支（这很多，但我想一段时间后他们可以被删除）

Answer 1

如果有几个人使用新功能（以及现有功能的改进）并且他们都使用dev分支来提交他们的代码，那么你永远无法确定dev分支是否稳定。如果开发人员使用功能分支来构建新功能，并且仅在功能完成时将这些功能合并到dev分支中，则dev分支始终应该是稳定的。 （然后也可以删除功能分支。）

我喜欢git flow的解决方案。您有一个主（生产）分支和一个开发分支。此外，还有功能分支，您可以在其中处理需要在生产中修复的事物的新功能和修补程序分支，并且不能等到下一个版本。