5

我们有一个网络应用程序，我们有几个企业客户。我们最近决定将其作为 SaaS 应用程序提供并遵循精益方法（与我们的企业产品并行）。这意味着我们正在进行可能无法投入生产的实验。

在我们精简之前，我们对以下分支策略感到满意（我相信这是非常标准的）：

  • 大师- 永远稳定
  • dev - 通常不稳定（功能分支从 dev 中截断，以便新功能进入下一个主要版本）
  • major_release_x - live（在 dev 合并到 master 后切断 master，这是修复错误并合并回 master 和 dev 的地方）

现在，除了上述内容之外，我们还有以下内容，但效果并不好：

  • lea_release_branch - live（切断major_release_x并包含实验）
  • Experiment_x - 切断major_release_x（这是我们将功能组合在一起然后将其合并到lean_release_branch的地方）

我们现在的情况是，我们需要按照精益方法的要求快速且经常地发布，当我们获得对任意事物的可靠反馈时，我们需要将其生产化并尽快发布（离开lea_release_branch）。

问题是我们不能从dev创建一个特性分支（因为它很可能是不稳定的）并且我们不能从lea_release_branch创建一个特性分支，原因有两个：

  1. 它已被实验代码污染，因此此更改/功能将无法返回master
  2. 精益发布分支总是需要准备好发布，所以如果有需要修复和发布的关键问题，我们不能忙于对其进行测试和修复（在将更改/功能合并到其中之后）

有人知道我们设置的更好策略吗？

4

3 回答 3

2

除了 GitFlow nozari 提到的，还有GitHub Flow。我工作的地方以此为基础（master 总是稳定的，在功能分支中开发，在合并之前拉取请求并进行审查）。我们部署的频率比 GitHub 少，所以在 master 上，我们使用带注释的标签来跟踪发布，轻量级标签指向现在处于暂存/生产中的任何提交。这是由capistrano-deploytags Ruby gem 管理的。

除非我错误地阅读了您的问题，否则您可以使用此策略实现相同的效果，而所有这些分支的复杂性都较低。

于 2013-06-28T10:04:17.813 回答
0

我刚刚从 TFS 更改为 GIT，我遵循的模型基于这篇文章。

关于您的实验，它只是“特色分支”，不会使其重新开发（合并到开发中）。

于 2013-06-28T00:11:08.217 回答
0

因为major_release_x中的所有内容都已经在dev中（因为dev在上一个主要版本之前被合并到master中），可以在major_release_x的功能分支上完成生产化功能（在成功的实验之后） ，称之为production_feature_y，然后合并到两个dev，将在下一个主要版本中，以及lean_release_branch。

这样，您的精益版本中就可以使用新的生产功能，并将在下一个主要版本中使用，并且精益分支永远不需要再次合并回来。

客户对该功能的进一步反馈可以在production_feature_y上实现，并再次合并到dev和lean_release_branch中。

错误修复可以以相同的方式处理，在major_release_x的分支上完成，并合并到major_release_x和lean_release_branch中。

于 2013-06-28T08:46:57.230 回答