跟踪发布，分支还是标签？

Question

你如何跟踪你的版本？

目前，我们有两个主要分支机构。

• 开发人员
• 发布

几个人正在进行的开发总是发生在dev中。一旦完成了足够数量的更改，代码就会被合并到release中，然后从它构建并在其中进行标记。然后部署代码。

问题：这个功能很好，但是经常会出现新的bug，这些bug目前在开发分支中得到了处理。继续前进(有时有很多)。一旦问题得到解决，客户发布的新构建通常同时包含修复和一些新功能。

我想将此过程更改为：

• 当前<-当前开发流，最新和最大的，尚未部署
• prod <-目前在prod中，合并自dev/1.0.2
• dev/1.0.0 <-一段时间前已建成并交付生产
• dev/1.0.1 <- bug修复到以前的构建，将构建并交付prod
• dev/1.0.2 <- bug修正到以前的构建，构建并交付给prod。目前在prod

你认为如何？这一趋势会持续很长一段时间吗？我们每年发布大约15次，每次发布至少有2-3次刺激后的事故需要修复，因此粗略地说，我们每年将有75个分支(这是很多，但我想过一段时间他们可以被移除)。

Answer 1

如果有几个人在新特性(以及现有特性的改进)上工作，并且他们都使用dev分支来提交代码，那么您永远无法确保dev分支是稳定的。如果开发人员使用功能分支构建新特性，并且只在功能完成时将这些特性合并到dev分支中，那么开发分支应该始终是稳定的。(然后特性分支也可以被删除。)

我喜欢git flow的解决方案。您有一个主(生产)分支和一个开发分支。此外，还有一些特性分支，您可以在这些分支中处理新特性和修补程序分支，以解决生产中需要修复的问题，并且不能等到下一个版本发布。