使用 --depth 1 进行浅克隆、创建提交并再次拉取更新是否安全？

Question

git clone的--depth 1选项：

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

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

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

我喜欢浅层克隆的想法 - 例如 drupal 核心：当我从 7 开始时，我没有办法知道在 drupal 4 中发生了什么。 - 但我不想用脚射击自己。

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

Answer 1

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

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

文档现在显示：

--depth <depth>::

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

这源于诸如0d7d285 、 f2c681c和c29a7b8 之类的提交，它们支持克隆、使用/来自浅层克隆的发送包/接收包。
smart-http 现在也支持浅取/克隆。

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

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

---

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

这是“ Documentation/user-manual.txt ”

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

只要合并基础在最近的历史记录中，就可以在<<def_shallow_clone,shallow clone>>内部合并。
否则，就像合并无关的历史一样，可能会导致巨大的冲突。
这种限制可能使这样的存储库不适合在基于合并的工作流中使用。

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 。

Answer 2

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

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

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

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

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