我们使用git 来分发操作系统并使其保持最新状态。我们无法分发完整的存储库，因为它太大（>2GB），所以我们一直在使用浅克隆（~300M）。但是最近从浅层克隆中获取时，它现在获取整个 >2GB 存储库的效率很低。这是对部署带宽的一种站不住脚的浪费。
git 文档说您不能从浅层存储库中获取，尽管这绝对不是真的。是否有任何变通方法git clone --depth 1可以获取从中更改的内容？或者其他一些策略来保持分布大小尽可能小，同时让所有位 git 需要进行更新？
我尝试克隆 from--depth 20以查看它是否会更有效地升级，但没有成功。我也确实查看了http://git-scm.com/docs/git-bundle，但这似乎创建了巨大的捆绑包。
--depth是一种git fetch选择。我看到文档并没有真正强调git clone进行提取。
当您获取时，这两个存储库通过从远程的头部开始并向后搜索获取的参考历史中最近的共享提交来交换关于谁拥有什么的信息，然后填写所有丢失的对象以仅完成新提交之间的新提交最近的共享提交和新获取的提交。
A --depth=1fetch 只是获取分支提示，没有先前的历史记录。这些历史的进一步获取将通过上述过程获取所有新的内容，但如果先前获取的提交不在新获取的历史中，则 fetch 将检索所有这些 - 除非您使用--depth.
您的客户从一个 repo 中提取了 depth=1 并将 url 切换到了不同的 repo。在这个新的 repo 的 refs 中，至少有一个很长的祖先路径显然与你的 repo 中当前的任何东西没有任何提交。这可能值得研究，但无论哪种方式，除非有某种特殊原因，您的客户可以只做每一次 fetch --depth=1。
刚刚做g clone github.com:torvalds/linux了，花了很多时间，所以我跳过了它CTRL+C。
然后做了g clone github.com:torvalds/linux --depth 1，它确实克隆得很快。而且我在git log.
所以clone --depth 1应该工作。如果您需要更新现有存储库，则应使用git fetch origin remoteBranch:localBranch --depth 1. 它也有效，它只获取一个提交。
加起来：
初始克隆：
git clone git_url --depth 1
代码更新
git fetch origin remoteBranch:localBranch --depth 1
请注意，Git 1.9/2.0（2014 年第一季度）在获取浅层克隆方面可能更有效。
请参阅提交 82fba2b，来自Nguyễn Thái Ngọc Duy ( pclouds)：
现在 git 支持从浅克隆或向浅克隆传输数据，这些限制不再适用。
所有详细信息都在“ shallow.c：选择新提交的 8 个步骤.git/shallow”中。
您可以在0d7d285、f2c681c和c29a7b8之类的提交中看到结果，这些提交支持克隆、带有/来自浅克隆的发送包/接收包。
smart-http 现在也支持浅获取/克隆。
您甚至可以从浅层 repo 中克隆。
2015 年更新：git 2.5+（2015 年第二季度）甚至允许单次提交获取！请参阅“从远程 git 存储库中拉取特定提交”。
2016 年更新（10 月）：git 2.11+（2016 年第四季度）允许获取：
如果你可以选择一个特定的分支，它可以更快。下面是一个使用 Spark master 分支和 latest 标签的例子：
初始克隆
git clone git@github.com:apache/spark.git --branch master --single-branch --depth 1
更新到特定标签
git fetch --depth 1 origin tags/v1.6.0
以这种方式切换标签/分支变得非常快。
我不知道它是否适合您的设置，但我使用的是在单独的目录中完全克隆一个 repo。然后我参考本地存储库从远程存储库进行浅克隆。
git clone --depth 1 --reference /path/to/local/clone git@some.com/group/repo.git
这样，实际上只获取了与参考存储库和远程的差异。为了使其更快，您可以使用该--shared选项，但请务必阅读git文档中的限制（这可能很危险）。
我还发现，在某些情况下，当遥控器发生很大变化时，克隆会开始获取太多数据。最好打破它并更新参考存储库（奇怪的是，它占用的带宽比最初占用的要少得多。）然后再次启动克隆。