git克隆中的——depth 1选项:
创建一个浅克隆,其历史记录被截断为指定的修订数。浅存储库有许多限制(您不能从它复制或获取,也不能从它推入或进入它),但如果您只对具有较长历史的大型项目的最近历史感兴趣,并且希望以补丁的形式发送修复,那么浅存储库就足够了。
但我已经成功地做了一个浅克隆,提交了一些更改,并将这些更改推回到(裸克隆)原始版本。
这对我来说很有意义,为什么不呢?当克隆的HEAD在源文件中是可识别的,并且我的提交是在此基础上进行的,似乎没有理由。但是手册上不是这么说的。
我喜欢浅层克隆的想法——比如drupal核心:当我从drupal 7开始工作时,我不可能需要知道drupal 4里发生了什么。-但我不想搬起石头砸自己的脚。
那么,浅克隆、在其中开发提交、再次拉取以跟上原始更新是否安全?
注意,Git 1.9/2.0(2014年第一季度)已经取消了这一限制。
参见commit 82fba2b, from nguybind Thái ngeconc Duy (pclouds):
现在,git支持数据从一个浅克隆或传输到一个浅克隆,这些限制不再成立。
现在的文档如下:
--depth <depth>::
创建一个“浅”克隆,其历史被截断为指定的修订数。
这源于像0d7d285、f2c681c和c29a7b8这样的提交,它们支持克隆,用/from浅克隆发送包/接收包。
Smart-http现在也支持浅抓取/克隆。
所有细节都在“shallow.c:为.git/shallow选择新提交的8个步骤”中。
2015年6月更新:Git 2.5甚至允许获取单个提交!
(终极浅箱)
2016年1月更新:Git 2.8(2016年3月)现在正式记录了获取最小历史记录的实践。
参见Stephen P. Smith(' ')(' ')的commit 99487cf、commit 9cfde9e(2015年12月30日)、commit 9cfde9e(2015年12月30日)、commit bac5874(2015年12月29日)和commit 1de2e44(2015年12月28日)。
(由Junio C Hamano—gitster—在commit 7e3e80a中合并,2016年1月20日)
这是文档/user-manual。txt
A <<def_shallow_clone,shallow clone>> is created by specifying the git-clone --depth switch.
The depth can later be changed with the git-fetch --depth switch, or full history restored with --unshallow.
Merging inside a <<def_shallow_clone,shallow clone>> will work as long as a merge base is in the recent history.
Otherwise, it will be like merging unrelated histories and may have to result in huge conflicts.
This limitation may make such a repository unsuitable to be used in merge based workflows.
2020年更新:
Git 2.11.1引入了选项Git fetch——shallow-exclude=来防止获取所有历史记录
Git 2.11.1引入了选项Git fetch——shallow-since=来防止抓取旧的提交。
有关浅克隆更新过程的更多信息,请参见“如何更新git浅克隆?”。
正如理查德·迈克尔所评论的:
要填满历史:git拉——不浅
Olle Härstedt在评论中补充道:
要回填历史的一部分:git fetch——depth=100。