我们有一个目前正在生产的网站（代码位于“生产分支”下的TFS中），我们还有一组新功能正在一个名为“功能分支”的单独分支中开发。功能分支是使用生产分支作为其父分支创建的。到目前为止，通过将代码从功能分支推送到QA服务器来完成对新功能的测试。
问题：假设我们要开发另一组功能，在发布后管理分支的最佳方法是什么？
选项a：在将新功能部署到生产之后（我们计划将代码从功能分支推送到生产服务器）我们可以将功能分支中的代码合并到生产分支并开发功能分支中的下一轮新功能再次出现。但是由此产生的生产分支可能存在问题（合并错误？），因此我会担心将其部署到生产中而不花一些时间重新测试生产分支。另外，如果我们在一段时间后发现我们的功能分支需要回滚，该怎么办？如果我们单独离开旧的生产分支，我们就可以简单地将该分支推向生产，这将使一切恢复到以前的工作状态。如果我们在发布后将发布分支合并到生产分支中，那就不再那么容易了。
选项b：我们可以将现有的功能分支视为我们的新生产分支，并创建一个新的分支（例如，“功能分支2”）并停止使用我们以前的生产分支。这似乎可以正常工作，但我们最终会有一长串的分支，建立在彼此之上。这似乎可能在某些时候变得混乱。不知道这是否真的是一个问题，除了必须知道我们目前在链中的哪个位置。
有没有人有这些不同策略的经验，如果是这样的话，你建议选择哪一个（或者有更好的第三选择）？
**更新2016年3月25日** 最后我选择了a。在将功能分支发布到生产之后，我等待了几天以确保它是稳定的，为功能分支制作了一些修补程序，并根据需要推送到生产环境。然后，当我有理由确定发布已按计划进行时，我将从功能分支合并到生产分支。然后，我对合并进行了完整性检查，以验证所有内容都正常。此时，生产分支又回到了真正的生产分支，功能分支用于下一轮新功能。
答案 0 :(得分：0)
在将新功能部署到生产之后（我们计划将代码从功能分支推送到生产服务器）我们可以将功能分支中的代码合并到生产分支并开发下一轮功能分支中的新功能再次出现。
这意味着生产中的内容与生产分支中的内容不匹配。 （或可能不匹配，这同样糟糕。）它依赖于合并成功而无需实际测试合并。
我们可以将现有的功能分支视为我们的新生产分支，并创建一个新的分支（例如，“功能分支2”）并停止使用我们之前的生产分支。
那里的最终比赛是什么？当你进入“功能分支137”时，你可能会开始质疑这种方法的智慧。
你实际上发现的是，分支和合并是，痛苦。合并基本上是制作和测试代码更改的行为，而实际上并没有提供任何商业价值。这是对cruft的定义。除非该公司真的出售源控制分支机构，否则这是不必要的开销。
那么......为什么要把所有这些分支放在首位呢？这听起来像是人为发明的问题。暂时考虑一下没有永久分支的战略 ......
您可以为各种事物创建临时分支。原型设计功能需要比迭代更长的时间，一个用于技术概念验证的沙箱更改（例如尝试一个全新的DAL框架）等等。但是所有内容都依赖于单一的“事实来源”代码库。
将“生产”分支和“开发”分支并排作为永久固定装置基本上意味着您有两个真实来源。只要你有多个真相来源，你就没有真相来源。
答案 1 :(得分：0)
在一个理想的情况下，你有一个分支线，你可以通过进行改变来连续交付生产，这些改变可以促使生产渠道发挥作用。所有功能和错误修复锄头通过相同的过程。
在你的情况下，要达到目标需要很多成熟度，所以你可能需要两个分支。一个用于生产（和修复），另一个用于新功能。
在master / main / trunk上，您通过自动发布管道练习连续发布。让每个签入都创建一个构建，然后将其部署到测试服务器。一旦获得批准，它将自动推送到下一个环境，直到您开始生产。
在dev / feature / notprod上，您可以直接从构建到开发/测试环境进行持续交付。在这里添加新功能并对其进行测试。一旦你感到高兴并且已经稳定下来，包括从master中提取错误修正，你就可以合并Back to master并开始发布过程。
如果您使用的是TFS 2013/2015，您可以：http://nkdagility.com/create-release-management-pipeline-professional-developers/
如果您使用的是VSTS，则可以：http://nkdagility.com/the-high-of-release/