Question

我们正在建立一个全新的TFS 2010服务器，之前没有使用过TFS（或者，令人恐惧的是，没有其他中央源管理系统）。这是我们的小团队（6-7名程序员）谈到设置的一般结构，我很好奇，基于其他人使用TFS的经验，如果这是一个好主意或不是（这些名称只是描述而不是什么我们计划使用）：

$/
    Our Organization's Collection/
        .Net technology projects/
            class libraries projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            ASP.NET projects/
                Project 1/
                Project 2/
                Project 3/
                etc.../
            Windows Workflow Foundation projects/
                etc.../
            WPF projects/
                etc.../
        Other non .NET source code/
        SQL/
        Server configuration/

（依此类推）

使用一年后，我们会后悔这种结构吗？应用程序将跨越此结构的许多部分 - 这将是一个需要管理的问题吗？

我们在什么级别设置了release / main / dev分支？

感谢您的任何意见和建议！

Answer 1

立即筹划。必要时进行分支。

对于从未管理过分支/合并的团队，我完全建议尽可能简单地开始（意味着，忘记短期分支）。在最近将我们的源代码从VSS转换为TFS2010并为具有相似经验水平的类似规模的团队实施了分支质量策略之后，我的建议如下：

在您需要之前不要实施分支策略。一旦确定有必要，您可以随时进行分支。继续将项目带入TFS进行源代码管理，确保每个人都对软件和团队合作保持稳定。

在此期间，找到感兴趣的团队成员，让他们有时间在您的代码库的并行或简化实例上进行研究，培训，测试和练习。他们需要在模仿部署过程的情况下练习创建项目，分支和合并;他们需要时间与团队的其他成员沟通，以微调您的流程并记录他们;随着学习曲线趋于平缓，他们需要愿意成为团队其他成员的资源。通过这种方式，您可以让团队成员做好准备，并有信心加强并实施您选择的分支模式。

在确定需要之前，您不希望跳转到分支策略。有大量的管理费用涉及大量的危险。

随着说：

一旦你开始分支以满足需求，我认为你不会在管理你拥有的东西时遇到任何麻烦。这里的关键是确保您不会过度设计这一点并使源/部署的管理变得复杂。还要知道TFS的结构将反映在本地文件系统/工作区中。

我们为每个独立解决方案或相关重用库组创建了一个单独的团队项目。在一个案例中，我们将一组高度依赖的解决方案组合在一个团队项目下 - 一个部署在一起的大型多应用程序内部网门户。这样做可以让我们简化部署和源代码管理。下面我们来看一下这个高级别的分支结构：

Large Intranet Solution

这是一个包含许多子项目的大型项目。每个分支都是完整的副本（只是差异/版本存储在服务器上）。集合中有大量的团队项目在这个项目的上方和下方，看起来很像你的名单。

最终答案取决于应用程序的相互依赖性，结构和部署策略。您对那里的结构有任何具体问题吗？

Answer 2

除了@ hangy的链接，如果它的TFS 2010你的设置然后codeplex's Visual Studio TFS branching guide详述了2010年的当前智慧。

Team Foundation Server 2010分支设置

2 个答案: