【发布时间】：2016-11-05 12:02:24
【问题描述】：
我们正处于从 SVN 迁移到 Git 的过程中，但面临一些我们还无法回答的关键实际问题。
目前我们有一个包含 100 多个项目的大型 SVN 存储库。
它们由 3 个 Jenkins 作业构建，即许多项目由同一个作业构建，并且它们也总是一起发布（尽管它们只是松散耦合）。
此设置无法更改，因为不可能维护 100 多个 Jenkins 作业，并且每个作业都需要大约 3GB 的磁盘空间（无论它构建了多少项目）。
如果将其与 3 个以上的活动分支相乘，这将完全耗尽我们的可用资源。
简单的解决方案是将一个 SVN 存储库转换为一个 Git 存储库，一切正常。
然而，由于 Git 不允许在存储库中设置目录权限，而且这也不是我们所了解的正确的“Git 方式”，因此拆分存储库会非常好。
然后我们回到许多 Jenkins 工作问题。
原则上，似乎可以为每个 Jenkins 作业指定一个以上的 Git 存储库，但如果添加更多存储库，这也会很快无法维护，因为 Jenkins GUI 不擅长处理许多条目。忘记向作业添加新存储库的可能性也很高。
因此，我们查看了子模块、子树和子存储库，以便在一堆存储库上创建一致的（只读）视图。
此视图（或其中的几个）应集中管理，Jenkins 作业只需检查此视图并获取构建项目所需的一切。
由于视图的简单更新将从所有包含的存储库中提取最新版本。但是，据我了解，这不适用于任何方法，因为它们要么需要特殊命令将包含的存储库更新到最新的远程版本（Jenkins Git 插件无法做到），要么甚至需要提交到将模块指针向前移动到最新版本。
所以这是一个简单的问题：如果不使用一个大型存储库，您将如何使用 Git 解决这个问题？
【问题讨论】：
-
Google's REPO 擅长操纵多个 git repos。