使用–depth 1进行浅克隆是否安全,创build提交并再次提取更新?

git clone--depth 1选项:

创build一个历史截断为指定修订版本的浅表副本。 一个浅层的存储库有一些限制(你不能从中克隆或取出,也不能从中推入或者推入),但是如果你只关心一个历史悠久的大型项目的最近历史,并且想要发送修补程序作为补丁。

但是我已经成功完成了一个浅层克隆,提交了一些更改,并将这些更改推回(裸露克隆)源。

这对我有意义 – 我的意思是为什么不呢? 当克隆的HEAD在起源中是可识别的,并且我的承诺在此之上时,似乎没有理由。 但是手册另有说明。

我喜欢浅层克隆的想法 – 例如drupal核心:从7开始,我不需要知道drupal 4中发生了什么,但是我不想让自己陷入困境。

那么浅层克隆是否安全,开发提交,再次拉动来源于更新?

请注意,Git 1.9 / 2.0(2014年第1季度)已经消除了这个限制。
参见NguyễnTháiNgọcDuy( pclouds ) 提交的82fba2b :

现在,git支持从一个浅层克隆的数据传输,这些限制不再是真实的。

该文档现在读取 :

 --depth <depth>:: 

创build一个历史被截断为指定修订版本的“浅”克隆。

这源自像0d7d285 , f2c681c和c29a7b8这样的提交,它们支持克隆,与浅层克隆的send-pack / receive-pack。
smart-http现在也支持浅取/克隆 。

所有的细节都在“ shallow.c :为.git/shallowselect新提交的8个步骤 ”。

2015年6月更新: Git 2.5甚至允许提取一个提交
(最终浅的情况下)


2016年1月更新:Git 2.8(2016年的马赫)现在正式logging获得最低限度历史的做法。
参见提交99487cf , 提交9cfde9e (2015年12月30日), 提交9cfde9e (2015年12月30日), 提交bac5874 (2015年12月29日),并提交Stephen P.Smith (“)的 1de2e44 (2015年12月28日) 。
(由Junio C gitster合并- gitster -在7e3e80a ,2016年1月20日提交 )

这是“ Documentation/user-manual.txt

通过指定git-clone --depth开关来创build<<def_shallow_clone,shallow clone>>
稍后可以使用git-fetch --depth开关更改深度,或使用--unshallow恢复完整历史logging。

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


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

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

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

最难的是得到一个Use Case权利(即自我一致),所以分布式的,因此可能不同的回购协议仍然会一起愉快地工作。

它看起来好像是checkout --orphan是正确的“build立”阶段,但仍然缺乏干净(即简单易懂的一行命令)在“克隆”步骤的指导。 相反,您似乎必须init一个回购协议,build立一个remote跟踪分支(您只需要一个分支?),然后fetch那个单独的分支,这个分支感觉很长,有更多的错误机会。

编辑:对于“克隆”一步看到这个答案