我们正在考虑将当前的TFVC团队项目纳入一个GIT monorepo。
支持或反对monorepos的论据都不是非常令人信服的。现在，在TFVC中链接不同的团队项目时遇到了问题，这就是我们考虑采用monorepo的原因。我们考虑使用GIT，因为TFVC在合并和检测文件移动方面存在严重问题。即使直接告诉Visual Studio IDE这是一个举动，而不是删除/添加，这似乎也应该落后10-20年。
我现在想知道使用monorepo时的构建速度。
构建代理足够聪明
这样可以加快流程吗？
或者通常是整个仓库的克隆，在构建之后，我将必须执行任何构建步骤，例如程序集版本控制，仅对新的构建进行更新，并且也要采取适当的措施（始终为TFVC保留文件）每周一次删除构建代理上的源文件？
关于多个构建定义：每个构建定义都必须获得自己的存储库克隆吗？总共有5个构建，完全不同的解决方案以及主要解决方案的不同分支。
其他信息：团队很小（我们不是Google），整个存储库大小约为1-2GB。我们现在正在TFS 2017上，没有立即升级的计划。
答案 0 :(得分：1)
only get what it needs (folders/files)目前尚无法指定要在“获取源代码”步骤中下载的文件的一部分。与使用映射不同，它似乎仅在使用TFVC时可用。
由于 Git依赖于完整的存储库状态（提交是指向工作文件夹状态的指针，该状态包括该状态下的所有文件），因此无法仅获取某些文件或仓库中的文件夹。
但是，为了加快构建过程，请每次获取完整的git repo。您可以设置clean = false并检查阴影提取以仅在构建过程中获取修改的文件。
浅获取：：仅允许您下载存储库的最新快照。下载速度会更快，但可能会导致工具 就像GitVersion失败（它依靠历史数据来计算 版本号）。
清洁：错误：将保留先前构建的内容，使您可以增量获取源代码，增量构建 使用支持它的工具。您可以将Clean：False与自定义结合使用 进行更有针对性的清理的步骤。
有关更多详细信息，您还可以在我们的官方文档中查看get source code part的Azure DevOps Git。
此外，如果您的仓库太大或其中的二进制文件太多。 考虑将其拆分为较小的存储库，或者如果二进制文件较多，请使用Git-LFS作为二进制文件。