git - Azure Devops : Checkout step slow: to many objects?

Question

首先是一些背景信息:我们目前正在将一个大的 git 存储库从 Bitbucket 迁移到 Azure Devops。存在一些挑战，因为存储库的历史充满了二进制 blob，事后看来这是完全没有必要的。

在之前尝试过 bfg-repo-cleaner 之后，我们最终使用了 git filter-repo 并成功地将 repo 大小从几 GB 减少到“刚好”在 400 MB 左右(取决于您的计数)。我们还重写了一些标签名称。

我们的过程是首先从 bitbucket 中创建一个新的克隆，然后运行一个 shell 脚本来缩小 repo。之后，我们将存储库推送到我们在 Azure Devops 中创建的新空白存储库。

这一切比我们预期的要容易得多。 git filter-repo 速度非常快，整个过程不超过一个小时。

在我们感到安全地进行移动之前(并迫使我们所有的开发人员卡住存储库一段时间)，我们进行了几次测试运行以确保我们没有丢失任何数据并且 Azure Devops 管道可以构建我们的代码就像 Bamboo 曾经做的一样好。

我们成功制作了一个 yml 流水线，总共运行大约需要 4 分钟。对我们解决了所有问题充满信心，我们开始真正地完成整个过程。一切顺利，我们迅速将所有开发人员转移到新存储库。

问题:然后我们注意到我们的新管道比我们之前的测试花费了更长的时间来构建。在对日志进行一些挖掘之后，我们发现它与下载对象有关。

New Repo(Checkout 总共需要 8 分钟)

remote: Found 39837 objects to send. (1316 ms)

Receiving objects: 100% (39837/39837), 809.66 MiB | 1.69 MiB/s, done.

测试 Repo(Checkout 总共需要 31 秒)

remote: Found 11772 objects to send. (358 ms)

Receiving objects: 100% (11772/11772), 80.17 MiB | 8.75 MiB/s, done.

我认为值得一提的是我们在 checkout 时使用了 --depth=1。在我们的测试管道中，这大大缩短了 checkout 时间。

现在我们很高兴一切正常，我们可以告别同时托管 bitbucket 和 bamboo 的昂贵 VPS，但对我们习惯的较长构建时间感到沮丧。

我怀疑我们的包文件在某种程度上不够优化，因此您需要下载更多文件以“克隆”存储库。我说“克隆”是因为管道似乎初始化了一个新的 repo 协议(protocol)，添加了一个远程并获取。当我在本地开发机器上进行真正的克隆时，只需要 5 分钟(包括通过 Internet 传输和解析增量)。我觉得这很奇怪。

如有任何帮助，我们将不胜感激。谢谢，

皮特·埃克哈特

Answer 1

原来问题是在我们之前的测试中我们没有将标签从 bitbucket 推送到 azure devops。

当我们确实推送标签时，azure devops 中的 checkout 过程需要更长的时间，因为 --tags 在您有很多标签时会抵消 depth=1 的影响。

参见:https://developercommunity.visualstudio.com/idea/878730/git-source-provider-add-ability-to-pull-git-repos.html