首先：将所有内容都放在一个 TPC 中，无论是 Visual Studio Online 还是自托管服务，除非您是一家拥有多个部门的大型公司。即便如此，我认为您实际上并不需要多个 TPC。
其次：通常你会希望尽可能少地使用团队项目；您拥有的越多，更新流程模板、工作项等时维护的可能性就越大。如果您跨产品使用相同的流程模板，这可以让生活变得更简单。
第三：Blankenship 等人的 Professional Team Foundation Server 2012 书中有一个很棒的部分。关于各种场景的分支/版本控制设置，包括这个，但我会重复我认为与您相关的内容，以及对我们有用的内容（嗯，我正在帮助我们朝着什么方向前进）。
这可能有点离题，但我认为我需要更深入一点才能正确回答这个问题。
让我从基本的分支结构开始。
- 产品 1：主要，然后是开发和发布分支。
- 产品 2：Main，然后是 Dev 和 Release 分支。
- 内部库：Main，然后是 Dev 和 Release 分支。
这里有几个问题 - 您是否希望将内部库发布为 .dll、NuGet 包或 .csprojs 等包含在您的 Prod1 和 Prod2 解决方案中？
假设 .dlls/nuget
为简单起见，并避免我们遇到棘手的问题，我们假设我们有 Prod 1 和 Prod 2 使用相同版本的已发布内部库发布分支。任何要完成的修复都被视为针对发布的生产修补程序，然后重新发布发布并将修补程序合并到其他分支。
针对 Dev 进行内部代码的持续开发，针对 Main 进行稳定化/RC。
假设您将内部库项目直接添加到 Prod1/Prod2 解决方案 - 创建解决方案文件夹 InternalLibraries，然后在其中添加 .csprojs。问题是您指的是内部图书馆的哪个分支？您需要多么前沿来回答这个问题 - 如果发布，您就可以发布 dll 或 NuGet。如果是 Main，您可以帮助验证 Internal Library 是否已准备好合并到 Release 和发布。如果是 Dev，你是一个勇敢的灵魂，基本上在做持续集成，所以我会考虑取消 Internal Library Dev 分支并坚持使用 Main 和 Release。或者您可以匹配分支 - Prod1 Dev -> Internal Library Dev、Prod1 Main -> Internal Library Main 等。这种假设内部库和您客户的产品的发布周期相同。
好的，这在源代码管理中会是什么样子？假设每个产品有一个团队项目：
$/Prod1
主要的
开发
发布
$/Prod2
主要的
开发
发布
$/内部库
主要的
开发
发布
在解决方案中：
Prod1.sln
内部库\
内部库1
AllYourOtherStuff\
我确实建议将您的分支保持在同一级别（即 $/Prod1/Main 和 $/Prod1/Dev 而不是 $Prod1/Main 和 $/Prod1/Features/Feature1，因为如果在您直接将内部 .csproj 文件添加到您的 Prod1 .sln。如果您使用 .dll 或 NuGet 发布，这会变得更容易。
那么您只需要正确设置本地和 Team Build 工作区，您就（应该）是金子了。
显然还有很多关于这个主题的内容，但如果我的思路是正确的，并且您需要更多反馈，请告诉我。我有一种感觉，这可能已经是矫枉过正或没有回答问题：-P