问题描述
首先是一些背景信息： 我们目前正在将一个大型 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 分钟才能运行。 对我们解决了所有问题充满信心，我们开始真正地完成整个过程。 一切都很顺利，我们很快将所有开发人员转移到了新的存储库。
问题： 然后我们注意到我们的新管道比我们之前的测试花费的时间更长。 在对日志进行了一些挖掘后，我们发现它与下载对象有关。
新 Repo（结帐总共需要 8 分钟）
远程：找到 39837 个要发送的对象。 （1316 毫秒）
接收对象：100% (39837/39837)，809.66 MiB | 1.69 MiB/s，完成。
Test Repo（结帐总共需要 31 秒）
远程：找到 11772 个要发送的对象。 （358 毫秒）
接收对象：100% (11772/11772)，80.17 MiB | 8.75 MiB/s，完成。
我认为值得一提的是，我们在结账时使用了 --depth=1。在我们的测试管道中，这大大缩短了结账时间。
现在我们很高兴一切正常，我们可以告别昂贵的 VPS 托管 bitbucket 和竹子，但我们习惯了更长的构建时间。
我怀疑我们的包文件在某种程度上没有得到足够的优化，所以你需要下载更多的文件来“克隆”存储库。我说“克隆”是因为管道似乎初始化了一个新的存储库，添加了一个远程和获取。 当我在本地开发机器上进行真正的克隆时，只需要 5 分钟（包括通过互联网传输和解析增量）。我觉得这很奇怪。
任何帮助将不胜感激。 谢谢，
皮特·埃克哈特
解决方法
原来的问题是，在我们之前的测试中，我们没有将标签从 bitbucket 推送到 azure devops。
当我们推送标签时，azure devops 中的结账过程会花费更长的时间，因为 --tags 当您有很多标签时会抵消 depth=1 的影响。