关于TFS分支策略有几个/很多问题，但我无法提出适合我的方案的策略。我的TFS项目由一个包含Web项目，业务层项目和数据层项目的解决方案组成。该项目是报告的门户。报告主要在项目的子文件夹中隔离。但是整个项目中有一些功能，例如会话管理。在给定的时间段内，工作流程可能如下所示：
基本上，每份报告都是完全独立的时间表。我需要能够独立地将代码分支发布到我们的不同环境中。目前，我们没有分支 - 如果项目在报告未准备好但包含在项目中时发布，我们就不会添加新功能的链接。不是最好的方案。
我最初采用的分支策略是让Main位于QA和prod环境之间，基本上只是一个容器，在分支到生产发布的生产分支之前进行合并。每份报告都将在main的一个分支上开发。对于我们的测试和qa环境，将创建main的分支，并将适当的开发分支合并到此“建议的更新”分支中。这不起作用，因为我将开发/功能分支合并到一个不是父分支的分支。我不能将Main作为这个级别，因为报告可能正在开发数周，而另一个报告可能正处于一个时间表上，该时间表已经开发并在短短几天内推进到生产过程。我的“建议的更新”分支用于测试和qa需要能够从仅合并的适当的dev分支中独立创建。
我唯一的分支/合并经验是一对主+开发分支，所以我在这里非常不合适。如何以这样的方式设置我的分支：我能够在独立的时间表上合并功能而不会卡住并且代码在准备好之前发布到环境中？
如果重要，我们现在正在参加TFS 2008，并希望尽快进入TFS 2010。这是迫切需要开始使用我们当前的TFS 2008服务器。
答案 0 :(得分：2)
我对一切都不是很清楚;阅读理解和所有。
据我了解，您目前的流程是 Dev - ＆gt;测试 - ＆gt; QA - ＆gt;生产即可。开发人员处理代码，将其推送到可以对其进行测试的环境中。一旦满意，他们就会将其推向QA，当代码通过时，它就会进入生产阶段。
此外，您有几个“团队”（1个或多个开发人员）必须处理不同的报告，每个报告最终都必须通过上述流程转移到生产中。团队可能正在处理与其他团队不同的代码，或者团队可能会发现他们无法将代码移动到其他团队达到稳定之前。
如果我负责分支这个解决方案，我建议如下。
首先，创建生产分支。该分支仅包含生产代码。只有你的QA团队接触过这个分支。
接下来，创建 QA 分支。该分支机构也由QA团队独家维护。他们手动将测试代码合并到此分支中，运行其质量保证测试，然后与Production合并。每次他们与生产合并，或测试代码被接受到QA中时，标签就会应用于分支。如果测试代码失败，则分支将恢复为先前的标签。
开发团队管理自己的分支机构。它们是通过最新标签的 QA 分支创建的。这可以确保他们使用最新批准的代码。开发人员在此分支上工作并进行测试。如果团队彼此依赖，他们应该在同一个分支上工作，除非很明显从共享的 Dev 分支创建辅助分支会更容易。一旦 Dev 分支符合为开发人员设置的里程碑，就应该告知QA分支已准备好与QA合并进行测试。
或者，取决于开发的复杂程度，您甚至可以考虑将 QA 和生产分支联合起来。通常，向分支添加标签以指示稳定的，有价值的构建是一件简单的事情。它还使分支策略尽可能简单，这总是一件好事。
答案 1 :(得分：0)
我认为你应该看看由VS ALM Rangers组织的分支指导。
http://tfsbranchingguideiii.codeplex.com/
这应该包括你的所有问题。您正在寻找一个非常先进的分支计划。我的博客上也有一些很好的实用指导。我知道我在谈论Scrum团队，但它是基于指南的基本功能分支。
http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx
如果有机会请投票 在新的“Visual Studio ALM” StackExchange在Area51中就像我们一样 试图建立一个专门的地方 回答这些问题 Visual Studio ALM MVP和Visual 工作室ALM游骑兵在手边回答 你的问题。
http://area51.stackexchange.com/proposals/15894/visual-studio-alm
答案 2 :(得分：0)
[我知道这个问题很旧，但这可能会帮助遇到此问题的其他人]
大多数“每个功能部门”团队使用一个“主要”分支，并根据环境方法脱离该分支。通过在MAIN分支上清楚地标记每个环境释放，可以处理环境释放。
QA发行是将所有经过充分测试并准备进行QA的功能部件/问题分支合并到MAIN中的结果。发现错误后，将从MAIN分支出新的错误分支，这些分支已修复并合并回MAIN。当所有QA版本都准备就绪后，即可使用MAIN制作PROD版本。简而言之，MAIN是代码真实性的来源之一。
如果您需要继续工作，可以使用集成测试分支（TEST）来确定哪些功能已“可以投入生产”，但应根据具体情况将功能/问题分支合并到MAIN中，而不是从TEST分支机构批量购买。
修补程序可以从PROD标签中分支出来，然后进行修复，测试并合并回MAIN，以发布新的PROD。
我将向您推荐有关每个功能分支的精彩视频。它侧重于GIT，但是这些策略不依赖于GIT，并且可以与TFS SCC一样有效地使用：https://youtu.be/9SZ7kSQ2424