在perspers中，我们可以启用并行同步/提交，这意味着如果有200个新文件需要从服务器中提取，p4v客户端将打开5-10个与服务器的连接，并并行拉取并发文件。 这使得传输速度有了巨大的提高，这意味着单个线程上的差异为 30Mbps，8 个并发线程上的差异为 240Mbps，特别是因为我们的仓库每周都会收到 10 GB 的更新。
我一直在四处寻找是否可以使用我们的 Gitlab 服务器启用类似的东西，但我还没有找到任何东西。 这是我在这个主题上找到的唯一内容，它只是对 git-annex： https://git-annex.branchable.com/forum/Feature_request__58___Multiple_concurrent_transfers/
有谁知道这是否可能，如果是的话，你会好心地为我指出正确的方向吗？
谢谢！
只要你不一次传输一个对象（即，不以愚蠢的方式执行此操作），客户端的fetch进程使用客户端和服务器之间的流连接，客户端发送一系列"想要/已经拥有"，因为服务器提供一系列"有"，以确定客户端需要哪些对象。 然后，一旦商定了对象，服务器就会将这些对象聚合到一个精简包中。 此精简包针对客户端已知具有的对象进行增量压缩。
非浅层存储库，服务器可以信任客户端不仅具有被拒绝的对象，还具有所有前置对象，因此即使对于相当大的对象集也会生成微小的包文件（当然，这取决于实际存在的前置文件，以及服务器针对这些对象快速压缩的能力）。 例如，假设 200 个新文件或更新文件与 200 个以前的版本非常相似。 薄包可能基本上由 200 组指令组成，上面写着"复制旧1234567...然后在中间添加 6 个字节"而不是"这里是 200 GB 的原始数据"。
这种精简包需要相当长的 CPU 时间来生产，但即使是最慢的链路也能在几秒钟内传输。
显然，如果 200 个新对象与任何以前的对象都没有相似之处，彼此之间也没有相似之处，增量压缩将无济于事。 在这种情况下，薄包将仅从 zlib 放气压缩产生的任何东西中受益。
在任何情况下，获取客户端都会收到（单个）精简包文件，并通过从客户端已有的对象中添加缺失的基础来将其修复为非精简包。 因此，正如T0xicCode回答的那样，无论如何都只有一个文件被传输。
Git 目前在单个连接中传输内容。目前无法通过其网络协议发送分块内容。正如 torek 提到的，git 会做一些处理来减少需要传输的数据的大小。因此，git 通常通过其单个连接传输的内容少于最后重建的内容。