一个新的精益团队的Git分支策略
我们有一个网络应用程序，我们有几个企业客户。我们最近决定将其作为SaaS应用程序提供，并采用精益的方式(与我们的公司产品并行)。这意味着我们已经进行了一些试验，这些实验可能无法投入生产。
在我们开始瘦身之前，我们对以下分支策略感到满意(我认为这是非常标准的)：
- 主-总是稳定的
- dev -通常是不稳定的(功能分支切断了dev，以使新特性进入下一个主要版本)
- major_release_x - live (在dev合并到主版之后切断主版，这是错误修复的地方，并将其合并到master和dev中)
现在，除了上面的内容之外，我们还有以下几个方面，而且它并没有很好地工作：
- lean_release_branch - live (切断major_release_x并包含实验)
- experiment_x -切断major_release_x (这是我们将该功能合并到lean_release_branch中的地方)
我们现在的场景是，我们需要按照精益方法的要求快速、经常地发布，当我们得到一些任意的东西的可靠反馈时，我们需要生产它并尽快发布它(在lean_release_branch之外)。
问题是我们不能在lean_release_branch的dev上创建一个特性分支(因为它很可能是不稳定的)，并且我们不能创建一个从的特性分支，原因有两个：
- 它已经被实验代码污染了，所以这种更改/特性将无法返回到主
- lean_release_branch总是需要随时准备发布，所以我们不能忙于对它进行测试和修复(在将变更/特性合并到其中之后)，如果存在需要修复和发布的关键问题
有人知道我们的设置有更好的策略吗？
回答 3
Stack Overflow用户
发布于 2013-06-28 10:04:17
除了提到GitFlow nozari之外，还有GitHub流。我所工作的地方作为一个基础(主人总是稳定的，在特性分支中开发，在合并前用评审拉出请求)。我们部署的频率比GitHub少，因此在主服务器上，我们使用带注释的标签跟踪发行版和轻量级标记，指向当前在暂存/生产中提交的内容。这是由capistrano部署标记 Ruby管理的。
除非我不正确地理解您的问题，否则您可以在所有这些分支中以较低的复杂度实现同样的策略。
Stack Overflow用户
发布于 2013-06-28 00:11:08
我刚刚从TFS变成了GIT，我遵循的模型是基于这个帖子的。
关于你的实验，它只是“特色分支”，不会使它回到开发(合并到开发)。
Stack Overflow用户
发布于 2013-06-28 08:46:57
因为major_release_x中的所有内容都已经在dev中(因为dev在上一个主要版本之前被合并到主中)，一个生产特性(在一个成功的实验之后)可以在major_release_x，的特性分支上完成，称为production_feature_y，，然后合并到dev和lean_release_branch.中。
这样，新的生产特性就可以在您的精益发行版中使用，并且将出现在下一个主要版本中，并且精益分支不再需要重新合并。
进一步的客户反馈可以在production_feature_y上实现，并再次合并到、dev、和lean_release_branch中。
Bug修复可以以同样的方式处理，在major_release_x上的分支上完成，并合并到major_release_x和lean_release_branch.中。
https://stackoverflow.com/questions/17355062
复制相似问题
腾讯云开发者
