它是安全的浅克隆——深度1，创建提交，并再次拉更新?

git clone中的--depth 1选项:

创建一个浅克隆，其历史记录被截断为指定的修订数。浅存储库有许多限制(您不能从它复制或获取，也不能从它推入或进入它)，但如果您只对具有较长历史的大型项目的最近历史感兴趣，并且希望以补丁的形式发送修复，那么浅存储库就足够了。

但我已经成功地做了一个浅克隆，提交了一些改变推动了这些变化回到(裸克隆)的起源。

这对我来说很有意义，为什么不呢?当克隆的HEAD在源文件中是可识别的，并且我的提交是在此基础上进行的，似乎没有理由。但是手册上不是这么说的。

我喜欢浅层克隆的想法——比如drupal核心:当我从drupal 7开始工作时，我不可能需要知道drupal 4里发生了什么。-但我不想搬起石头砸自己的脚。

那么，浅克隆、在其中开发提交、再次拉取以跟上原始更新是否安全?

169875 次浏览
小开

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

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

困难的部分是获得一个正确的用例(即自洽)，这样分布式的，因此可能发散的回购仍然可以愉快地一起工作。

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

编辑:关于“克隆”步骤，请参见这个答案

小开
最佳答案
注意Git 1.9/2.0 (2014 Q1)有删除这个限制 参见提交82年fba2b, from ngibmc Duy (pclouds):

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

文档现在为:

--depth <depth>::

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

这源于类似0 d7d285， f2c681c和c29a7b8的提交，它们支持克隆，发送包/接收包与/from浅克隆 Smart-http现在也支持浅抓取/克隆 . < / p >

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

更新2015年6月:Git 2.5甚至允许获取单个提交!
(最终浅大小写)

2016年1月更新:Git 2.8(2016年3月)现在正式记录了获取最小历史记录的实践 参见斯蒂芬·p·史密斯(“”)的提交99487 cf， 提交9 cfde9e(2015年12月30日)，提交9 cfde9e(2015年12月30日)，提交bac5874(2015年12月29日)和提交1 de2e44(2015年12月28日) (由Junio C Hamano—gitster—在提交7 e3e80a中合并，20 Jan 2016)

这是"Documentation/user-manual.txt"

通过指定git-clone --depth开关创建<<def_shallow_clone,shallow clone>> 稍后可以使用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

并且大车Harstedt添加了在评论中:

要回填历史的部分: git fetch --depth=100。


提交答案