301

中的--depth 1选项git clone：

创建一个浅克隆，其历史被截断为指定的修订数。浅层存储库有许多限制（您不能克隆或从中获取，也不能从中推送或进入），但如果您只对历史悠久的大型项目的近期历史感兴趣，并且想要作为补丁发送修复。

但是我已经成功地完成了一个浅克隆，提交了一些更改并将这些更改推回（裸克隆）原点。

这对我来说很有意义——我的意思是为什么不呢？当克隆的 HEAD 在源中可识别时，我的提交在此之上，似乎没有理由。但手册上另有说明。

我喜欢浅克隆的想法 - 例如drupal核心：当我从7开始时，我不需要知道drupal 4中发生了什么。 - 但我不想在脚上开枪。

那么浅克隆、在其中开发提交、再次拉取以跟上来自源的更新是否安全？

4

2 回答 2

324

请注意，Git 1.9/2.0（2014 年第一季度）已删除该限制。
请参阅提交 82fba2b，来自Nguyễn Thái Ngọc Duy ( pclouds)：

现在 git 支持从浅克隆或向浅克隆传输数据，这些限制不再适用。

该文档现在显示：

--depth <depth>::

创建一个“浅”克隆，其历史记录被截断为指定的修订数。

这源于像0d7d285、f2c681c和c29a7b8这样的提交，它们支持克隆、带有/来自浅克隆的发送包/接收包。
smart-http 现在也支持浅获取/克隆。

所有详细信息都在“ shallow.c：选择新提交的 8 个步骤.git/shallow”中。

2015 年 6 月更新：Git 2.5 甚至允许获取单个提交！
（终极浅案）

2016 年 1 月更新：Git 2.8 (Mach 2016) 现在正式记录了获取最小历史的做法。
请参阅Stephen P. Smith (``)的commit 99487cf、commit 9cfde9e（2015 年 12 月 30 日）、commit 9cfde9e（2015 年 12 月 30 日）、commit bac5874（2015 年 12 月 29 日）和commit 1de2e44（2015 年 12 月 28 日） 。（由Junio C Hamano 合并——在提交 7e3e80a中，2016 年 1 月 20 日）
gitster

这是“ Documentation/user-manual.txt”

A<<def_shallow_clone,shallow clone>>是通过指定git-clone --depth开关创建的。
稍后可以使用git-fetch --depth开关更改深度，或使用 恢复完整历史记录--unshallow。

<<def_shallow_clone,shallow clone>>只要合并基础在最近的历史中，就可以在 a 中合并。
否则，就像合并无关的历史一样，可能会产生巨大的冲突。
此限制可能使此类存储库不适合在基于合并的工作流中使用。

2020 年更新：

  • git 2.11.1 引入git fetch --shallow-exclude=了防止获取所有历史记录的选项
  • git 2.11.1 引入git fetch --shallow-since=了防止获取旧提交的选项。

有关浅克隆更新过程的更多信息，请参阅“如何更新 git 浅克隆？ ”。

正如理查德迈克尔评论的那样：

回填历史记录：git pull --unshallow

Olle Härstedt在评论中补充道：

回填部分历史记录：git fetch --depth=100.

于 2014-01-19T13:19:51.380 回答
5

查看我的类似问题Why-cant-i-push-from-a-shallow-clone 的一些答案以及 git 列表上最近线程的链接。

最终，repos 之间的“深度”测量并不一致，因为它们从各自的 HEAD 测量，而不是 (a) 你的 Head，或 (b) 你克隆/获取的提交，或 (c) 其他东西你想到了。

困难的一点是让一个人的用例正确（即自洽），以便分布式的，因此可能是不同的 repos 仍然可以愉快地一起工作。

它看起来确实checkout --orphan是正确的“设置”阶段，但在“克隆”步骤中仍然缺乏干净的（即简单易懂的单行命令）指导。相反，看起来您必须init创建一个 repo，设置一个remote跟踪分支（您是否只想要一个分支？），然后fetch是那个单一的分支，感觉很长，有更多出错的机会。

编辑：对于“克隆”步骤，请参阅此答案

于 2011-08-04T23:26:38.903 回答