4

你如何跟踪你的发布？

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

  • 开发者
  • 释放

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

问题：这很好用，但通常会出现新的错误，这些错误目前在开发分支中处理，已经......继续前进（有时很多）。一旦问题得到解决，提供给客户的新版本通常包含修复和一些新功能。

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

  • 当前 <- 当前开发流，最新和最好的，尚未部署
  • prod <- 当前在 prod 中，从 dev/1.0.2 合并
  • dev/1.0.0 <- 前段时间构建并交付给 prod
  • dev/1.0.1 <- 对先前构建的错误修复，将被构建并交付给 prod
  • dev/1.0.2 <- 对先前版本的错误修复，将被构建并交付给 prod。目前在生产中

你怎么看？这种趋势会奏效并长期可持续吗？我们每年发布大约 15 次，每个版本至少有 2-3 次生产后事故需要修复，所以大致而言，我们每年将有 75 个分支（这是很多，但我想过一段时间他们可以被删除）

4

1 回答 1

4

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

我喜欢git flow. 您有一个主（生产）分支和一个开发分支。还有一些功能分支，您可以在其中处理新功能和修补程序分支，用于需要在生产中修复并且不能等到下一个版本的东西。

于 2012-08-04T21:16:45.690 回答