2016 年 1 月更新：Git 2.8（2016 年马赫）现在正式记录了获取最小历史记录的实践。
请参阅提交99487cf，提交 9cfde9e（2015 年 12 月 30 日），提交 9cfde9e（2015 年 12 月 30 日），提交 bac5874（2015 年 12 月 29 日），以及提交 1de2e44（2015 年 12 月 28 日），作者：斯蒂芬·P·史密斯 (``)。
^{（由 Junio C Hamano -- gitster -- 合并于提交 7e3e80a，2016 年 1 月 20 日）}

这是“文档/user-manual.txt"

<> 是通过指定 git-clone --深度开关。
稍后可以使用 git-fetch --depth 开关，或使用 --unshallow 恢复完整历史记录。

只要合并基础位于最近的历史记录中，<> 内的合并就可以工作。
否则，就像将不相关的历史合并一样，可能会导致巨大的冲突。
此限制可能会使此类存储库不适合在基于合并的工作流程中使用。

2020 年更新：

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

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

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

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

和 Olle Härstedt 添加在评论中：

要回填历史记录的部分：git fetch --depth=100。

Note that Git 1.9/2.0 (Q1 2014) has removed that limitation.
See commit 82fba2b, from 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.

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 c29a7b8 which support clone, send-pack /receive-pack with/from shallow clones.
smart-http now supports shallow fetch/clone too.

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

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

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)}

This is "Documentation/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.

Update 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.

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

As commented by Richard Michael:

to backfill history: git pull --unshallow

And Olle Härstedt adds in the comments:

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

回复收藏 0 原文

番薯 2024-12-04 19:10:27

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

最终，存储库之间的“深度”测量并不一致，因为它们是从各自的 HEAD 测量的，而不是（a）您的 Head，或（b）您克隆/获取的提交，或（c）其他东西你心里有数。

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

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

编辑：有关“克隆”步骤，请参阅此答案< /a>