我在我的组织内成立了一个开发团队，我们在一个Azure DevOps项目下管理我们所有的计划。澄清一下，我尽量避免使用"项目"这个词。这里是为了防止与ADO项目术语混淆，所以我使用"主动性"。
随着时间的推移，我们期望维持大量的计划(随着时间的推移可能有数百个)，因为我们迎合了公司中的许多团体。我们的一些计划将彼此高度相关，但应该独立管理提交历史。对于相关的计划，我们更喜欢在一个单独的Repo下管理它们，但将它们分散到不同的文件夹中。例如，我们可能有一个dll，它将被许多相关的插件(如应用程序)大量使用。如果可能的话，最好将dll和插件应用程序维护在与子Repo相同的Repo中。此外，将有许多类别的相关计划将托管在其他Repo中。
我的问题是，在Azure Repos中，维护大量相关或不相关的项目的最佳实践是什么?我读了一些关于Git子模块的东西，但我正在努力弄清楚如何在Azure Repos中制作/管理杰出的子模块。这是最好的方法吗，或者它在ADO中可能吗?或者，为每个项目使用独立的仓库，并尝试通过预先确定的命名约定对它们进行分组，并且只调用管道中的多个存储库，这是更好的实践吗?
提前感谢!我对ADO比较陌生。
我同意mason的观点，子模块可能会很复杂，值得努力。
假设你正在开发web应用
你有repository "AwesomeApp"存放需要编译成产品代码的代码
你可以创建实用程序的repo " utilities ">
这个repo永远不会是公开的，只是为了你的方便而存在
在"utilitesrepo"下，您将有一些类似于以下的结构:
scripts/
development_build/AwesomeApp/
.gitmodules
azure_pipelines.yml
目录"development_build"将成为"awesomeapp"的顶级副本;使用子
在" utilities报告"的顶层，.gitmodules将有所有的信息下拉"AwesomeApp"副本用于构建/测试目的
[submodule "AwesomeApp"]
path = "development_build/AwesomeApp"
url = https://dev.azure.com/AwesomeApp
branch = CurrentDevBranch
用命令填充development_build/AwesomeApp:
git submodule update --init
Submodule path 'development_build/AwesomeApp': checked out 'CurrentDevBranch'
现在所有文件的副本将在development_build/AwesomeApp/
If "AwesomeApp"需要库，您可以将其添加为子模块，因为目录development_build只是其他repos副本的占位符
只需将其添加为子模块和您的脚本"可以访问和构建/测试两者:
development_build/AppLibrary/
development_build/AwesomeApp/