我们正在从SVN迁移到Git，但正面临一些我们无法回答的关键实际问题。
目前我们有一个包含100多个项目的大型SVN存储库 它们由3个Jenkins工作构建，即许多项目由同一个工作构建，并且它们也总是一起发布（尽管它们只是松散耦合）。
此设置无法更改，因为无法维护100多个Jenkins作业，并且每个作业都需要大约3GB的磁盘空间（无论它构建多少个项目）。
如果将其与3个以上的活动分支相乘，这将完全耗尽我们的可用资源。
简单的解决方案是将一个SVN存储库转换为一个Git存储库，一切都像以前一样工作 但是，由于Git不允许对repo中的目录设置权限，这也不是正确的＆＃34; Git方式＆＃34;正如我们所知，拆分存储库会非常好。
但接下来我们回到詹金斯的许多工作问题 原则上似乎可以为每个Jenkins作业指定多个Git存储库，但如果添加更多存储库，这也很快就无法维护，因为Jenkins GUI不擅长处理许多条目。忘记为工作添加新存储库的可能性也非常高。
因此，我们查看了子模块，子树和subrepo，以便在一堆存储库上创建一致（只读）视图。
这个视图（或其中一些）应该集中管理，Jenkins工作只需检查这个视图并获得构建项目所需的一切。
由于视图的简单更新将从所有包含的存储库中提取最新版本。但是，据我所知，这对任何方法都不起作用，因为它们要么需要特殊的命令来将所包含的存储库更新为最新的远程版本（Jenkins Git插件无法做到），甚至是提交将模块指针向前移动到最新版本。
所以这是一个简单的问题：如何在不使用一个大型存储库的情况下使用Git解决这个问题？
答案 0 :(得分：1)
由于视图的简单更新将从所有包含的存储库中提取最新版本。但是，据我所知，这不适用于任何方法，因为它们要么需要特殊命令才能将包含的存储库更新到最新的远程版本
使用Git子模块很容易做到：
要更新视图，您只需要：
git submodule update --remote --recursive