我正在为我和一位朋友设置Team Foundation Service。我们将用它来创建一些业余爱好项目。
我已经使用单个团队项目进行了设置，源控件目前的结构如此
$ \项目\ CommonLib
$ \项目\ PROJECT1
$ \项目\ Project2的
Project1是游戏，Project2是win8应用程序，commonlib是我们常用的可重用代码，Projec1和Project2都会引用它。每个项目都包含一个包含多个项目的解决方案。
需要将CommonLib分发到这两个项目。我最初的想法是将CommonLib二进制文件检查到源控制文件夹中，然后将其分支到另外两个项目，使用某种自定义Team Build流程进行部署。
但是有一个问题。像这样工作是相当繁琐的，特别是现在在开发的早期阶段。我们希望能够快速地向CommonLib添加代码，虽然上面描述的过程在代码库已经成熟并且不会经常修改时很好，但每次添加某些内容时都会执行所有这些步骤那里（build - ＆gt; deploy - ＆gt; merge）。
在规模的另一端，我们可以为例如创建一个开发解决方案。 Project1还包含CommonLib项目。但是，这意味着如果我们错误地导致更改，我们可能会导致Project2出现问题。使用上面描述的分支+合并策略可以更好地管理这个
所以我的问题是，我是否遗漏了任何可能使我们保留控制权的选项，同时仍然能够将开发过程的复杂性保持在最低限度？我确信这是一个常见的问题。
答案 0 :(得分：1)
如果您没有将二进制文件合并到产品空间中会有帮助吗？
$\Projects\CommonLib\1.0\Source
$\Projects\CommonLib\1.0\Bin
$\Projects\CommonLib\Dev\Source
$\Projects\CommonLib\Dev\Bin
$\Projects\Project1
$\Projects\Project2
为常见构建一个构建，让它将二进制文件检入Bin文件夹，然后让Project1和Project2共同引用它们。正如你所看到的，我还在普通的Dev分支中加入了一个1.0分支，这样当Project1或Project2 gewt准备好发布时，他们可以将公共dev分支到一个版本化的文件夹中，并将自己从其他项目中切换到常见的。
答案 1 :(得分：0)
是否有任何理由不能在同一个构建解决方案中同时拥有这两个项目，即使每个开发人员只对其中一个项目感兴趣？
将两个项目放在一个解决方案中，并将共同项目放在同一个解决方案中，然后无论何时你们中的任何一个对公共模块进行更改，你都会立即知道是否已经破坏了任何一个依赖项目中的内容，因为所有内容都是一起构建的。然后，您可以更新由更改为公共模块而破坏的相关代码，或者与项目所有者协调以更新该代码。随着项目的成熟，您应该会看到对常见模块的更改变少。
在所有内容都清理干净并且单元测试通过之前，请不要检查您的重大更改。如果对常用模块进行重大更改，则需要负责修复所有相关代码。这为在不破坏已发布的界面或语义的情况下进行核心更改的技能构建了特性和新的认识。 ;＆GT;
显然，这种“包括一切”的方法无法与大型开发团队和大量项目一起扩展。但是，当您与更大的团队合作时，您应该切换到自动构建/共享构建服务器工作流，其中依赖项目决定他们依赖哪些中间体构建，并且可以决定何时“汇总”到更新版本的模块依赖于 - 独立于依赖模块的发布周期。对于具有公共代码的两个开发人员和两个项目，您不需要此级别的依赖关系管理。