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

小编典典

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

all

中的--depth 1选项git clone：

创建一个浅
克隆，其历史被截断为指定的修订数。浅层存储库有许多限制（您不能克隆或从中获取，也不能从中推送或进入），但如果您只对历史悠久的大型项目的近期历史感兴趣，并且想要作为补丁发送修复。

但是我已经成功地完成了一个浅克隆，提交了一些更改 并将这些更改推 回（裸克隆）原点。

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

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

那么浅克隆、在其中开发提交、再次拉取以跟上来自源的更新是否安全？

阅读 92

2022-04-21

共1个答案

小编典典

请注意，Git 1.9/2.0（2014 年第一季度）已删除该限制。
参见提交
82fba2b，来自Nguy峄卬
Th谩i Ng峄峜 Duy ( pclouds)：

现在 git 支持从浅克隆或向浅克隆传输数据，这些限制不再适用。

该文档现在显示：

--depth <depth>::

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

这源于像0d7d285、f2c681c和c29a7b8这样的提交，它们支持克隆、带有/来自浅克隆的发送包/接收包。
smart-http
现在也支持浅获取/克隆。

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

这是“ Documentation/user- manual.txt”

A<<def_shallow_clone,shallow clone>>是通过指定git-clone --depth开关创建的。
稍后可以使用git-fetch --depth开关更改深度，或使用
恢复完整历史记录--unshallow。

<<def_shallow_clone,shallow clone>>只要合并基础在最近的历史中，就可以在 a 中合并。
否则，就像合并无关的历史一样，可能会产生巨大的冲突。
此限制可能使此类存储库不适合在基于合并的工作流中使用。

2020 年更新：

git 2.11.1 引入git fetch --shallow-exclude=了防止获取所有历史记录的选项
git 2.11.1 引入git fetch --shallow-since=了防止获取旧提交的选项。

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

补充：

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

2022-04-21