新精益团队的Git分支策略

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

之前，我们去了精益我们很高兴与下面的分支策略（我相信这是非常标准）：

主 - 总是稳定
开发 - 经常不稳定（功能分支切断开发新功能到进入下一个主要版本）
major_release_x - 生活（切断主后开发已合并成高手，这就是bug修复发生，并且合并到主和DEV）

现在我们有除了上述以下，它的工作不那么好：

lean_release_branch - 生活（切断major_release_x并包含实验）
experiment_x - 切断major_release_x（这是我们破解功能一起，则m二哥成lean_release_branch）

我们的情景，现在是我们需要释放快，往往作为精益方法使然，而当我们的东西任意获得坚实的反馈，那么我们就需要productionize它并尽快释放尽可能（关闭lean_release_branch）。

的问题是，我们不能创建一个特性分支关闭开发的（因为它是最有可能是不稳定的），我们不能有两个原因创建一个特性分支关闭lean_release_branch的：

已经通过实验代码污染使这一变化/功能将无法做它的方式回到主
的lean_release_branch总是需要准备发布，所以我们不能忙做如果存在需要修复和发布的关键问题，则可以对其进行测试并进行修复。

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

来源

2013-06-27 Markus Coetzee

在第二个最后一段中，你的意思是说，在对某个实验的良好反馈后，重做功能必须成为精益释放的一部分？它何时成为主要版本的一部分？ –

@NieldeWet我所指的“坚实的反馈”应该与实验无关。因此，我们需要立即制作并尽快从lean_release_branch发布，然后它需要找到进入未来主要发行版的路径。 –

我刚刚从TFS更改为GIT，我遵循的模型基于此post。

关于你的实验，它只是“精选分支”，不会让它回到开发（合并到开发）。

来源

2013-06-28 00:11:08 nozari

可能对nvie工作流程有一些不同的看法：https：//speakerdeck.com/ewoodh2o/a-sane-git-workflow – Zavael

因为一切都在major_release_x已经在开发（因为开发并入主上一个主要发行前）的productionised功能（以下成功的实验），可以在一个特性分支进行关闭major_release_x，称之为production_feature_y，然后合并成两个开发，成为下一个主要版本，并lean_release_branch。

通过这种方式，您的精益版本中可以使用新的生产特性，并将在下一个主要版本中发布，精益分支永远不需要再次合并。在功能

而且客户的反馈可以production_feature_y实现，并且合并到开发和lean_release_branch一次。

Bug修复可以以同样的方式来处理，在分支完成关闭major_release_x合并为两个major_release_x和lean_release_branch。

来源

2013-06-28 08:46:57

这实际上是我们如何生成了几条反馈，但它不太适合它违反了第一点。 2：“lean_release_branch总是需要准备好发布，所以如果需要修复和发布关键问题，我们就不能忙于测试和修复（在合并更改/功能之后）” –

好的，但是如果你正在自己的分支上进行生产功能，当它合并的时候，它应该是生产准备就绪并准备好发布了吗？ –

它首先必须发布到测试服务器，经过代码审查并在其功能分支上进行开发人员测试后，因此它需要进入具有构建作业的分支（但不是lean_release_branch，因为它需要100％稳定）。 –

除了GitFlow nozari提到，还有GitHub Flow。我工作的地方以此为基础（主人总是稳定，在特色分支中发展，在合并之前请求评论）。我们不太经常部署GitHub，因此我们使用annotated tags跟踪发布和轻量级标签，指向现在正在进行的任何提交。这是由capistrano-deploytags Ruby宝石管理的。

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

来源

2013-06-28 10:04:17 Rafe

新精益团队的Git分支策略

回答

相关问题