0

我目前正在尝试提出一种版本控制策略，用于将我们公司的代码和文档文件从集中式 SCM (Perforce) 移动到 Git。Perforce 中的内容只是一个存储所有项目的大型 Depot，出于多种原因，我想将其分解为多个较小的 Git 存储库。

我现在遇到的问题是如何索引所有这些存储库，以便轻松找到它们。据我所知，Git 没有任何用于管理多个存储库的内置工具。

我确实找到了git-submodule，但听起来那是为了创建一个包含其他存储库内容的存储库，我不想管理各种存储库的内容，而是管理存储库本身。

最初我正在考虑在我们的服务器上使用平面文件系统：

/repos
   -repo1.git
   -repo2.git
   -...
   -repoN.git

然后只是一个 git 命令来查询这个目录的所有存储库名称和关于内容的评论（有点像登录到服务器，进入/repos目录并运行 a git log）。我在想我可以让/repo自己成为一个git存储库（一个存储库的存储库），然后完全按照我刚才所说的去做，但这似乎是...... un-git-y。

所以我的问题是：

  1. 我是否缺少任何git用于管理这样的多个存储库的内置工具/功能？
  2. 我的想法是否正确，这git-submodule不是我想要帮助管理这个的？
  3. 对于这种类型的设置，您有什么好的策略吗？
4

1 回答 1

0

如果您想要一个纯 Git 解决方案，那么您正在寻找git-submodule.

尤其是当你说：

我在想我可以让 /repo 本身成为 Git 存储库（存储库的存储库）

这正是子模块的含义。

父 repo 将跟踪单个文件 - .gitmodules，该文件将路径与其他 repo 的修订版连接起来。

然而，根据我的经验，我得出的结论是 Git 子模块并不理想，尤其是当您与没有经验的 Git 用户打交道时。切换分支或更改子模块时可能会导致问题。一些 GUI Git 客户端不完全支持子模块。

但是，如果您只想跟踪这些文件夹，则可以使用子模块。

另一种方法是忽略主存储库中的此类文件夹，并在这些文件夹中拥有单独的 Git 存储库。Git 在这些文件夹中完美运行，无论它们在另一个 Git 存储库下。

此解决方案非常适用于应用程序项目中的供应商库。你可以使用包/依赖管理器来更新它们，或者只是cd和git pull.

于 2014-01-31T23:03:52.197 回答