大多数CI服务提供了浅层克隆存储库的方法。例如，在特拉维斯：
git:
depth: 1
或者在AppVeyor上：
clone_depth: 1
or
shallow_clone: true
这具有明显的速度优势，因为您不必克隆整个存储库。
CI服务的浅层克隆是否有任何缺点？是否存在浅层克隆会导致CI构建失败的情况？否则，为什么不浅层克隆这些CI服务的默认设置？
大多数CI服务提供了浅层克隆存储库的方法。例如，在特拉维斯：
git:
depth: 1
或者在AppVeyor上：
clone_depth: 1
or
shallow_clone: true
这具有明显的速度优势，因为您不必克隆整个存储库。
CI服务的浅层克隆是否有任何缺点？是否存在浅层克隆会导致CI构建失败的情况？否则，为什么不浅层克隆这些CI服务的默认设置？
它通常不会发生的原因有两个。
首先，浅层克隆的哈希值将与您在存储库中可能具有的任何版本不同。因此，无法跟踪您对任何特定结果所做的构建。
其次，如果没有细节，大多数Git服务器都能够发送优化的'everything.pack'。否则，服务器必须提供一个自定义提交包，其中只包含要发送给您的浅拷贝。因此，尽管可能有更多数据通过线路传输，但实际上可能会导致服务器上的更多工作。
最后，相当多的CI构建将执行某种标记操作并将其上载到存储库，并且您实际上不能标记浅克隆（参见第1点）。
添加到AlBlue的答案：
另一个问题是克隆深度设置也用于git子模块。
在使用git子模块的项目中，Travis等将从master开始克隆子模块repo，然后检查特定的修订版本。
如果我们在子模块中指向的提交不在当前主设备的n次提交中（其中n是深度设置），那么它将无法检出。