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

中的--depth 1选项git clone：

创建一个浅表副本，其历史记录被截断为指定的修订版本。浅层存储库有很多限制（您不能从中克隆或获取，也不能从中推入或推入其中），但是如果您仅对具有悠久历史的大型项目的最新历史感兴趣，并且想要将修补程序作为补丁发送。

但是我已经成功完成了一个浅表克隆，进行了一些更改并将这些更改推回到（裸克隆）源。

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

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

因此，浅表克隆，在其中进行开发，再次从源头进行更新以保持更新安全吗？

请注意，Git 1.9 / 2.0（2014年第一季度）已消除了该限制。
见提交82fba2b，从阮泰玉维战（pclouds）：

既然git支持从浅表克隆到浅表克隆的数据传输，那么这些限制不再成立。

该文档现在显示为：

--depth <depth>::

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

这源于诸如0d7d285，f2c681c和c29a7b8之类的提交，它们支持克隆，浅层克隆的send-pack / receive-pack和来自浅克隆的克隆。
smart-http现在也支持浅层抓取/克隆。

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

2015年6月更新：Git 2.5甚至允许获取单个提交！
（最浅的情况）

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

这是“ Documentation/user-manual.txt”

<<def_shallow_clone,shallow clone>>通过指定git-clone --depth开关来创建A。
以后可以使用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浅层克隆？ ”。

正如理查德·迈克尔（Richard Michael）所说：

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

而欧莱Härstedt增加的评论：

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

请参阅我的类似问题“ 为什么不能从一个浅表克隆中推送”的一些答案，以及指向git列表中最近线程的链接。

最终，“深度”度量在回购之间是不一致的，因为它们是根据各自的HEAD来度量的，而不是（a）您的Head或（b）您克隆/获取的提交，或（c）其他度量值你已经想到了。

困难的是正确使用用例（即自洽），以使分布的仓库（因此可能是不同的仓库）仍然可以快乐地一起工作。

看起来确实checkout --orphan是正确的“设置”阶段，但是在“克隆”步骤上仍然缺乏简洁（即，简单易懂的单行命令）指导。相反，看起来您必须进行init回购，设置一个remote跟踪分支（您是否只想要一个分支？），然后再fetch建立一个分支，这很容易导致出错的机会增加。

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