我目前正在尝试提出一种版本控制策略，以将我们公司的代码和文档文件从集中的SCM（Perforce）移至Git。Perforce中的内容只是一个存储所有项目的一个大仓库，由于多种原因，我想将其分解为多个较小的Git存储库。
我现在遇到的问题是如何索引所有这些存储库，从而可以轻松找到它们。据我所知，Git没有任何内置工具来管理多个存储库。
我确实找到了git-submodule，但这听起来好像是为了制作带有其他存储库的存储库，我不想管理各种存储库的 content 。
最初，我正在考虑我们的SEVER上的平面文件系统：
/repos
-repo1.git
-repo2.git
-...
-repoN.git
，然后只是一个git命令，以查询此目录中的所有存储库名称，并对内容进行评论（就像登录服务器一样，转到/repos目录并运行git log）。我以为我可以使/repo本身成为git存储库（存储库的存储库），然后做我刚才说的事情，但这似乎是如此... un-git-y。
所以我的问题是：
- 我是否缺少任何用于管理这样多个存储库的
git工具/功能？ - 我认为
git-submodule是不是我正在寻找帮助管理此问题的内容吗？ - 您是否看到过这种设置的好策略？
如果您想要纯git解决方案，那么您正在寻找git-submodule。
特别是当您说：
我以为我可以使/回购本身为git存储库（存储库的存储库）
这正是子模型。
父仓库将跟踪单个文件-.gitmodules，该文件将路径与其他存储库的修订连接起来。
但是，根据我的经验，我得出的结论是，Git子模型不是理想的，尤其是当您与经验不足的Git用户打交道时。它可能在切换分支或在子模块中进行更改时会引起问题。一些GUI GIT客户对子模型没有全力支持。
但是，如果您只想跟踪这些文件夹，则可以使用子模型。
另一种方法是忽略主回购中的此类文件夹，并在这些文件夹中具有单独的GIT存储库。git在这些文件夹中完美地工作，无论它们在另一个git repo下。
此解决方案对于应用程序项目中的供应商库非常有效。您可以使用软件包/依赖管理器更新它们，或者仅cd和git pull。