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

在之前尝试了bfg-repo-cleaner之后，我们最终使用了git filter-repo，并成功地将repo的大小从几个千兆字节削减到了400兆字节左右（取决于你计算的内容）。
我们的过程是首先从bitbucket创建一个新的克隆，然后运行一个shell脚本来缩小存储库。之后，我们将存储库推送到我们在Azure Devops中创建的新的空白存储库。
这一切都比我们预期的要容易得多。git filter-repo非常快，整个过程不超过一个小时。
在我们感到安全进行移动之前（并迫使我们所有的开发人员冻结存储库一段时间），我们进行了几次测试运行，以确保我们没有丢失任何数据，Azure Devops管道可以像Bamboo一样构建我们的代码。
我们成功地制作了一个yml流水线，总共花了大约4分钟的时间。我们确信我们解决了所有的问题，我们开始做整个过程的真实的。一切都很顺利，我们很快就把我们所有的开发人员转移到了新的仓库。

**问题：**然后我们注意到，我们的新管道比我们以前的测试花费了更长的时间来构建。经过对日志的一些挖掘，我们发现它与下载对象有关。
新回购（结账总共需要8分钟）

远程：找到39837个要发送的对象。（1316毫秒）
接收对象：100%（39837/39837），809.66 MiB| 1.69 MiB/s完成

测试回购（结账总共需要31秒）

远程：找到11772个要发送的对象。（358毫秒）
接收对象：100%（11772/11772），80.17 MiB| 8.75 MiB/s完成
我认为我们在检出过程中使用--depth=1是有意义的。在我们的测试管道中，这大大缩短了检出时间。
现在，我们很高兴一切正常，我们可以告别昂贵的VPS托管bitbucket和bamboo，但我们习惯了更长的构建时间。
我怀疑我们的包文件在某种程度上还不够优化，所以你需要下载更多的包文件来“克隆”仓库。我说“克隆”是因为管道似乎初始化了一个新的仓库，添加了一个远程的和获取。当我在本地开发机器上做一个真实的克隆时，只需要5分钟（包括通过互联网传输和解析增量）。我觉得这很奇怪。
任何帮助都将不胜感激。谢谢，
皮特·埃克哈特