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

Question

该--depth 1选件git clone:

创建一个浅层克隆,其历史记录被截断为指定的修订数.浅存储库有许多限制(您不能克隆或获取它,也不能从中推送或插入它),但如果您只对历史悠久的大型项目的近期历史感兴趣并且希望将修补程序作为补丁发送.

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

这对我有意义 - 我的意思是为什么不呢？当克隆的HEAD在原点可识别时,我的提交就在此之上,似乎没有理由.但手册说不然.

我喜欢浅层克隆的想法 - 例如drupal核心:当我从7开始时,我无法知道drupal 4中发生了什么 - 但我不想在脚下射击自己.

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

Answer 1

请注意,Git 1.9/2.0(2014年第一季度)已取消该限制.
见提交82fba2b,从阮泰玉维战(pclouds):

既然git支持从浅层克隆到浅层克隆的数据传输,那么这些限制就不再适用了.

该文档现在读:

--depth <depth>::

创建一个"浅"克隆,其历史记录被截断为指定的修订数.

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

所有细节都在" shallow.c:选择新提交的8个步骤.git/shallow ".

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 gitsterHamano合并- -在提交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>>只要合并基础在最近的历史中,在内部合并就会起作用.
否则,它就像合并不相关的历史,可能会导致巨大的冲突.
此限制可能使此类存储库不适合在基于合并的工作流中使用.

有关浅层克隆更新过程的更多信息,请参阅" 如何更新git浅层克隆？ ".

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

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

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

回填部分历史:git fetch --depth=100.

Answer 2

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

最终,回购之间的"深度"测量不一致,因为它们是从他们各自的HEAD,而不是(a)你的头,或(b)你克隆/提取的提交,或(c)其他东西测量你记得的.

硬比特正在使用一个用例(即自我一致),因此分布式的,因此可能不同的回购仍然可以愉快地一起工作.

它确实看起来checkout --orphan是正确的"设置"阶段,但仍然缺乏关于"克隆"步骤的干净(即简单易懂的一行命令)指导.相反,它看起来你需要init一个回购,设置一个remote跟踪分支(你只想要一个分支？),然后fetch那个单一的分支,感觉很长时间,错误的机会更多.

编辑:对于"克隆"步骤,请参阅此答案