在并行中拉取多个远程 Git 仓库

Question

我有一个拥有成千上万个远程库的 repo，我想一次从成千上万个远程库中进行拉取，最好可以指定同时进行的最大数量。在 manpages、谷歌或 git-scm 在线上，我没能找到与此相关的东西。请注意：我不想在多个 repo 上运行一个命令，我只有一个拥有成千上万个远程库的 repo。这与子模块无关，请不要讨论子模块。子模块与 Git 远程库无关。

- Incognito

---

可能是如何使用git clone --recursive加速/并行下载git子模块？的重复问题。 - phuclv

不，这与子模块无关。这是关于 Git 的完全不同的功能。 - Incognito

Answer 1

我很确定你需要编写自己的代码来完成此操作。

正如CodeWizard在评论中所说，Git需要锁定存储库的某些部分。如果在单个存储库中并行运行多个git fetch进程，则其中一些锁定可能会发生冲突。

您可能还需要一些远程订购策略，例如并行从remoteA、remoteB和remoteC收集，如果remoteB通常（但不总是）是remoteA和remoteC的超集，则可能会发现10000个共同对象在remoteB上，与其他两个相比。尽管这也适用于顺序的git fetch操作，但它变得不那么重要。例如，假设有5000个对象-一些提交、一些树和一些blob-在A上，您尚未拥有，5000个对象在C上，而所有10000个对象在B上。如果您按任何顺序顺序提取，您将先获取5k，然后5k，然后0；或者10k，然后0，然后0；因为当您移动到下一个远程时，您已经收集并存储了5k或10k个传入的对象。但是，如果您同时执行所有三个操作，您将带入5k、5k和10k个对象，只有然后才会发现您的工作量增加了一倍。

---

如果B始终是一个超集，那么首先按顺序转到B，然后仅为了其引用而并行访问A和C，这将指向你现在拥有的对象。

- torek

---

我的问题之所以好处理，是因为我确定没有常见的对象。但是有一件事让我感到奇怪...我认为git是事件源提交对象。在理论上，它应该能够收集n个提交引用，并稍后对它们进行完整性映射。我认为你说得对，我可能必须自己编写解决方案。 - Incognito

即使没有常见的提交，仍然可能存在共同的树或blob（尽管我认为会少一些）。但是有了无共同提交的保证，您可能希望研究在幕后使用git bundle，然后按顺序扫描（如运行git fetch）已完成的捆绑包，并更新给定远程的元数据。 - torek

Answer 2

从 Git 2.24 开始，使用 [--jobs] 选项可以实现 并行获取 多个远程仓库。

以下是一些示例：

获取 3 个远程仓库，其中 2 个将会并行获取：

git fetch -j2 --multiple remote1 remote2 remote3

获取所有远程分支，将并行获取5个远程分支：

git fetch -jobs=5 --all

如果你有成千上万的远程仓库，不想下载它们所有的内容，而是将它们分成一些逻辑组。你可以在 .git/config 文件中定义远程仓库组，而不是在命令行中指定它们（使用 --multiple 选项）。

[remotes]
    group1 = remote1 remote2 origin
    group2 = remote55 remote66

然后在fetch命令中使用这个组。

这个命令：git fetch --multiple -j4 group1 group2 remote10 会同时获取 remote1 remote2 origin remote55 remote66 remote10 这几个远程仓库，且会并行进行4次获取。

- Mariusz Pawelski

Answer 3

从Git 2.24开始，可以使用[--jobs]选项并行地同时拉取多个远程仓库：git pull。

然后确保使用Git 2.40（2023年Q1）：“ git fetch --jobs=0”^(man)曾经会触发BUG()，现在已经修复以使用可用的CPU。

请参阅 提交 c39952b（2023年2月20日），由Matthias Aßhauer (rimrul)完成。
^{（由Junio C Hamano -- gitster --于提交 d180cc2中合并，2023年2月24日）}

fetch：再次使用--jobs=0选择合理的默认值

^{报告者：Drew Noakes
签署者：Matthias Aßhauer}

在 51243f9（"run-command API：不要回退到online_cpus()"，2022-10-12，Git v2.39.0-rc0 -- merge列在batch #7中）之前，gitfetch --multiple --jobs=0``^(man)会选择一些默认的作业数量，类似于git -c fetch.parallel=0 fetch --multiple^(man)。
虽然我们的文档只承诺fetch.parallel会回退到“合理的默认值”，但对于--jobs也做同样的事情是有意义的。
因此回退到online_cpus()而不是BUG()出现问题。

这修复了“--jobs=0不再工作（git-for-windows/git issue 4302）”

- VonC