Pie*_*iet 5 git azure-devops azure-pipelines git-filter-repo
首先是一些背景信息： 我们目前正在将大型 git 存储库从 Bitbucket 迁移到 Azure Devops。存在一些挑战，因为存储库的历史充满了二进制 blob，事后看来这是完全没有必要的。
在之前尝试过 bfg-repo-cleaner 之后，我们最终使用了 git filter-repo 并成功地将 repo 大小从几 GB 削减到“仅仅”大约 400 MB（取决于您的计算）。我们还重写了一些标签名称。
我们的流程是首先从 bitbucket 创建一个新的克隆，然后运行一个 shell 脚本来缩小存储库。之后，我们将存储库推送到我们在 Azure Devops 中创建的新的空白存储库。
这一切比我们预想的要容易得多。git filter-repo 速度非常快，整个过程不超过一个小时。
在我们感到安全地进行移动之前（并迫使我们所有的开发人员将存储库冻结一段时间），我们进行了几次测试运行，以确保我们没有丢失任何数据，并且 Azure DevOps 管道可以同样好地构建我们的代码就像竹子以前做的那样。
我们成功制作了一条 yml 管道，总共运行大约需要 4 分钟。我们确信我们已经解决了所有问题，因此我们开始真正完成整个过程。一切都很顺利，我们很快将所有开发人员转移到新的存储库。
问题： 然后我们注意到我们的新管道的构建时间比之前的测试要长得多。经过一番挖掘日志后，我们发现它与下载对象有关。
New Repo（结账总共需要8分钟）
远程：找到 39837 个要发送的对象。（1316 毫秒）
接收对象：100% (39837/39837)，809.66 MiB | 1.69 MiB/s，完成。
测试Repo（结帐总共需要31秒）
远程：找到 11772 个要发送的对象。（358 毫秒）
接收对象：100% (11772/11772)，80.17 MiB | 8.75 MiB/s，完成。
我认为值得一提的是我们在结帐期间使用 --depth=1 。在我们的测试流程中，这大大缩短了结账时间。
现在我们很高兴一切正常，我们可以告别同时托管 bitbucket 和竹子的昂贵的 VPS，但对我们习惯的更长的构建时间感到沮丧。
我怀疑我们的包文件在某种程度上没有足够优化，因此您需要下载更多文件来“克隆”存储库。我说“克隆”是因为管道似乎初始化了一个新的存储库，添加了一个远程并获取。当我在本地开发机器上进行真正的克隆时，只需要 5 分钟（包括通过互联网传输和解析增量）。我觉得这很奇怪。
任何帮助将不胜感激。谢谢，
皮特·埃克哈特
事实证明，问题是在我们之前的测试中，我们没有将标签从 bitbucket 推送到 azure devops。
当我们推送标签时，azure devops 中的签出过程需要更长的时间，因为当您有很多标签时，--tags 会抵消深度 = 1 的影响。