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

Is it safe to shallow clone with --depth 1, create commits, and pull updates again?

提问by artfulrobot

The --depth 1option in git clone:

中的--depth 1选项git clone：

Create a shallowclone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

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

But I've successfully done a shallow clone, committed some changes and pushed those changesback to the (bare clone) origin.

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

It makes sense to me - I mean why not? when the cloned HEAD is identifiable in the origin, and my commit comes on top of this, there seems no reason. But the manual says otherwise.

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

I like the idea of shallow clone - e.g. of drupal core: there's no way I need to know what went on in drupal 4 when I've started from 7. - but I don't want to shoot myself in the foot.

我喜欢浅层克隆的想法 - 例如 drupal 核心：当我从 7 开始时，我没有办法知道在 drupal 4 中发生了什么。 - 但我不想用脚射击自己。

So is it safe to shallow clone, develop commits in it, pull again to keep up with updates from origin?

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

回答by VonC

Note that Git 1.9/2.0 (Q1 2014) has removedthat limitation.
See commit 82fba2b, from Nguy?n Thái Ng?c Duy (pclouds):

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

Now that git supports data transfer from or to a shallow clone, these limitations are not true anymore.

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

The documentation now reads:

该文档现在读：

--depth <depth>::

Create a 'shallow' clone with a history truncated to the specified number of revisions.

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

That stems from commits like 0d7d285, f2c681c, and c29a7b8which support clone, send-pack /receive-pack with/from shallow clones.
smart-http now supports shallow fetch/clone too.

这源于诸如0d7d285、f2c681c和c29a7b8 之类的提交，它们支持克隆、使用/来自浅层克隆的发送包/接收包。
smart-http 现在也支持浅取/克隆。

All the details are in "shallow.c: the 8 steps to select new commits for .git/shallow".

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

Update June 2015: Git 2.5 will even allow for fetching a single commit!
(Ultimate shallow case)

2015 年 6 月更新：Git 2.5 甚至允许获取单个提交！
（终极浅表）

---

---

Update January 2016: Git 2.8 (Mach 2016) now documents officially the practice of getting a minimal history.
See commit 99487cf, commit 9cfde9e(30 Dec 2015), commit 9cfde9e(30 Dec 2015), commit bac5874(29 Dec 2015), and commit 1de2e44(28 Dec 2015) by Stephen P. Smith (``).
^{(Merged by Junio C Hamano -- gitster--in commit 7e3e80a, 20 Jan 2016)}

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合并-- --in commit 7e3e80a，2016 年 1 月 20 日）}

This is "Documentation/user-manual.txt"

这是“ Documentation/user-manual.txt”

A <<def_shallow_clone,shallow clone>>is created by specifying the git-clone --depthswitch.
The depth can later be changed with the git-fetch --depthswitch, 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.

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

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

Update 2020:

2020 年更新：

• git 2.11.1 introduced option git fetch --shallow-exclude=to prevent fetching all history
• git 2.11.1 introduced option git fetch --shallow-since=to prevent fetching old commits.

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

---

---

For more on the shallow clone update process, see "How to update a git shallow clone?".

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

---

---

As commented by Richard Michael:

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

to backfill history: git pull --unshallow

回填历史： git pull --unshallow

And Olle H?rstedtadds in the comments:

和？欧莱^ h rstedt增加的评论：

To backfill partof the history: git fetch --depth=100.

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

回答by Philip Oakley

See some of the answers to my similar question why-cant-i-push-from-a-shallow-cloneand the link to the recent thread on the git list.

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

Ultimately, the 'depth' measurement isn't consistent between repos, because they measure from their individual HEADs, rather than (a) your Head, or (b) the commit(s) you cloned/fetched, or (c) something else you had in mind.

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

The hard bit is getting one's Use Case right (i.e. self-consistent), so that distributed, and therefore probably divergent repos will still work happily together.

困难的一点是让一个用例正确（即自洽），这样分布式的，因此可能不同的存储库仍然可以愉快地一起工作。

It does look like the checkout --orphanis the right 'set-up' stage, but still lacks clean (i.e. a simple understandable one line command) guidance on the "clone" step. Rather it looks like you have to inita repo, set up a remotetracking branch (you do want the one branch only?), and then fetchthat single branch, which feels long winded with more opportunity for mistakes.

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

Edit: For the 'clone' step see this answer

编辑：对于“克隆”步骤，请参阅此答案