我们将从内部TFS迁移到VSTS，但在我们承担将我们现有的代码从TFVC迁移到Git之前，我们会这样做。但是我想引起一些青少年并发症...
[我们现在有多个TFS项目（我们将其称为“ ProjectA”，“ ProjectB”等）。将其视为多个相互关联的产品，但是现在我们需要一个“ Suite”项目并将所有内容合并在一起。因此，新项目将是“ Suite”，并在其下方的文件夹中包含“ ProjectA”，“ ProjectB”等。
所有工作项都在另一个根项目下，但是我们必须分别处理这种情况。目前，只有代码，只有Main，并且我们可以承受相对较短的历史记录（对于较旧的历史记录查找，旧的TFVC项目将是只读的）。既然有十多年的历史和大量分支机构，我们需要划定一条合理的界限，我认为180天就足够了。
我的问题和摘要：我读过的大多数博客/文章都谈到了在同一个TFS项目中创建新回购并仅迁移该项目的更典型方法。我们要在new项目中创建一个新的存储库，并在子文件夹中迁移multiple其他项目，最后得到一个（大型）存储库。我需要事先了解任何警告吗？
一旦完成，我们将考虑将新项目迁移到VSTS。
[就像丹尼尔提到创建一个单一仓库不是一个好主意，您应该创建多个git仓库，使用组件（Nuget Artifacts）封装共享的部分，并从其他项目（在其他仓库中）使用它们。使用starian建议方法将每个项目迁移到git仓库要容易得多，然后您可以在本地克隆它们，将远程更改为新服务器（和单个项目），然后将其推送到那里。这样，您可以针对同一个目标项目创建多个存储库，并将所有子项目保留在自己的存储库中，并在闲暇时使用共享的组件。然后，您也可以独立于子项目独立地修订组件，这更好。开始时需要付出更多的努力，但未来会更好。
事实是，它们是[[not不相关的应用程序。它们都是相关的，现在我们有一个精心构建的过程，该过程使用环境变量进行构建以引用先前构建的输出。然后，安装程序项目将使用更为复杂的变量集来指向所有各种输出。在我们的构建机器上（使用TFS Build），我们有一个“全部构建”定义，该定义将来自所有单独的TFS项目的源获取到一个中央文件夹下，按正确的顺序构建它们，然后构建安装程序。
因此，我们的目标将是在构建时更紧密地匹配我们[[actually所做的工作，从而消除许多变量的源存储库。我们甚至可以选择制作一个可以一次性生成所有内容的.sln，因为大多数时候我们只是运行一个批处理文件来构建所有解决方案。我们实际上是想摆脱单独修订组件的麻烦，因为在现实生活中，我们只发布为一个捆绑包，因此没有理由暗示会改变。我们正在考虑-> Git迁移可能是解决我们过去的一些错误的机会（通过“我们的”，我的意思是在我前面的人都已经消失了）。 ：-）
我们可能必须使用Git-TFS，因为内置工具太局限了（我们在8个项目中仅拥有将近1.4Gig的源，而忽略了历史）。但是我们可能只会保留最少的历史记录，而将旧的TFVC项目保持只读状态，以进行较旧的历史记录查找。一个因素是TFS / VSTS构建环境。在创建新的构建定义时，第一步是填充“获取源代码”，如果您选择“ Azure Repos Git”，则只能选择
one
回购，而我们试图摆脱多个链接的构建定义，因为我们always
构建everything。我们已经在内部讨论过使用NuGet，但是由于在某一天，任何开发人员都可能在使用三或四个解决方案，因此将测试版本上载到NuGet只是为了将它们恢复到下一个解决方案中是不可行的。一个想法是，如果我们决定根本不需要迁移any
历史记录（因为旧项目仍然存在），那么从技术上讲，我们甚至不需要迁移“调整解决方案后，制作一个新的仓库（或仓库），仅复制源文件并上传为新项目。感谢您的反馈，这给了我一些思考的事情（其中之一就是放弃整个VSTS＆Git迁移，并保持现状。） ;-）
布拉德