git 克隆的深度是什么意思？
What does depth for git clone mean?
我们试图加快 CI 我们工作中的一个软件项目的构建。有人在项目生命周期的早期提交了一些巨大的（按照 git 的标准）二进制文件。重写 git 的历史只是为了摆脱它们似乎太麻烦了，所以我们认为做一个避免那些大的早期提交的浅层克隆就足够了。
我对克隆的 --depth 参数做了一些实验，遇到了一些奇怪的行为。 git clone 的 help 是这样说的：
--depth <depth>
Create a shallow clone with a history truncated to the specified number of commits. Implies
--single-branch unless --no-single-branch is given to fetch the histories near the tips of all
branches. If you want to clone submodules shallowly, also pass --shallow-submodules.
这表明 <depth> 将等于克隆期间将获取的提交数，但事实并非如此。这是我尝试不同的深度值时得到的结果：
| depth | commit count linux repo | commit count git repo |
|---------|-------------------------|-----------------------|
| 1 | 1 | 1 |
| 5 | 15 | 13 |
| 10 | 80 | 46 |
| 100 | 93133 | 39552 |
| 1000 | 788718 | 53880 |
为了克隆，我使用了这个命令 git clone --depth 10 https://github.com/torvalds/linux.git、git clone --depth 100 https://github.com/git/git.git，为了计算提交，我使用了这个命令 git log --oneline | wc -l。 （在工作中，我在 GitLab 服务器上观察到同样的事情，所以它不可能是 GitHub 工作方式的产物。）
有人知道这是怎么回事吗？深度值如何对应于实际下载的数据量？是我理解错了文档，还是有bug？
编辑：我为第二个回购添加了结果
--depth 表示克隆时要抓取的提交数。
默认情况下git下载所有分支的所有历史记录。
这意味着您的副本将包含所有历史记录，因此您将能够“切换”（签出）到您希望的任何提交。
添加 --depth 限制克隆的大小并仅检出最后 X 次提交
# Cloning a single branch with the following:
# clone specific branch and limit the history to last X commits
git clone --branch<...> --depth=<X>
How does the value for depth correspond to the actual amount of data downloaded?
with the --depth git will only download the content corresponding to the commits in the given range so the size of the repo will raise when the value is larger
This would indicate that will equal the number of commits that will be fetched during the
并非总是如此，如果这些提交中的任何一个是合并（例如没有快进），您将获得超过 X 次提交。
如何清理二进制文件：
Rewriting git's history just to get rid of them seems like too much trouble
此工具可以为您完成：
https://rtyley.github.io/bfg-repo-cleaner
###BFG Repo-Cleaner
an alternative to git-filter-branch.
The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:
*** Removing Crazy Big Files***
- Removing Passwords, Credentials & other Private data
Examples (from the official site)
In all these examples bfg is an alias for java -jar bfg.jar.
# Delete all files named 'id_rsa' or 'id_dsa' :
bfg --delete-files id_{dsa,rsa} my-repo.git
作为 ，您看到了合并的效果。
--depth 参数是指 Git 从每个起点开始 "walk" 的深度。正如您引用的文档中提到的那样，它还暗示 --single-branch，这简化了对此的讨论。这里的重点是遍历每个提交的 all parents，如果提交本身是一个合并，那么对于每个深度级别，它是不止一个提交。
假设我们有一个如下所示的提交图：
$ git log --graph --oneline master
* cf68824 profile: fix PATH with GOPATH
* 7c2376b profile: add Ruby gem support
* 95c8270 profile: set GOPATH
* 26a9cc3 vimrc: fiddle with netrw directory display
* 80b88a5 add ruby gems directory to path
[snip]
在这里，每个提交只有一个 parent。如果我们使用 --depth 3，我们将获取提示提交 cf68824，它的 parent 7c2376b 在深度 2，最后是 95c8270 在深度 3——然后我们停止了，提交了三个。
使用 Git 存储库 Git，但是：
$ git log --graph --oneline master
* 965798d1f2 Merge branch 'es/format-patch-range-diff-fix-fix'
|\
| * ac0edf1f46 range-diff: always pass at least minimal diff options
* | 5335669531 Merge branch 'en/rebase-consistency'
|\ \
| * | 6fcbad87d4 rebase docs: fix incorrect format of the section Behavioral Differences
* | | 7e75a63d74 RelNotes 2.20: drop spurious double quote
* | | 7a49e44465 RelNotes 2.20: clarify sentence
[snip]
对于 --depth 3，我们从 965798d1f2 开始，然后——对于深度 2——选取 both parents，ac0edf1f46 和 5335669531。为了添加深度 3 提交，我们选择了这两个提交的所有 parents。 ac0edf1f46的（单独的）parent在这里不可见，而5335669531的两个parent是（即6fcbad87d4和7e75a63d74） .要获取 ac0edf1f46 的 parent 的哈希 ID，我们可以使用：
$ git rev-parse ac0edf1f46^@
d8981c3f885ceaddfec0e545b0f995b96e5ec58f
所以这给了我们六个提交：master 的提示（当前是合并提交），该提交的两个 parent，其中一个 parent [=70] =]s，以及另一个 parent.
的两个 parents
根据您 运行 克隆 Git 的确切时间，tip-most master 通常不是合并，但通常将合并作为其直接 parent，这样 --depth 2 通常会得到 3 次提交，因此 --depth 3 会得到 至少 5 次，这取决于两个 parent master 的尖端本身就是合并。
（将上面的 git rev-parse 输出与：
进行比较
$ git rev-parse 965798d1f2^@
5335669531d83d7d6c905bcfca9b5f8e182dc4d4
ac0edf1f46fcf9b9f6f1156e555bdf740cd56c5f
例如。 ^@ 后缀表示 所有 parent 提交，但不是提交本身 。）
我们试图加快 CI 我们工作中的一个软件项目的构建。有人在项目生命周期的早期提交了一些巨大的（按照 git 的标准）二进制文件。重写 git 的历史只是为了摆脱它们似乎太麻烦了，所以我们认为做一个避免那些大的早期提交的浅层克隆就足够了。
我对克隆的 --depth 参数做了一些实验，遇到了一些奇怪的行为。 git clone 的 help 是这样说的：
--depth <depth>
Create a shallow clone with a history truncated to the specified number of commits. Implies
--single-branch unless --no-single-branch is given to fetch the histories near the tips of all
branches. If you want to clone submodules shallowly, also pass --shallow-submodules.
这表明 <depth> 将等于克隆期间将获取的提交数，但事实并非如此。这是我尝试不同的深度值时得到的结果：
| depth | commit count linux repo | commit count git repo |
|---------|-------------------------|-----------------------|
| 1 | 1 | 1 |
| 5 | 15 | 13 |
| 10 | 80 | 46 |
| 100 | 93133 | 39552 |
| 1000 | 788718 | 53880 |
为了克隆，我使用了这个命令 git clone --depth 10 https://github.com/torvalds/linux.git、git clone --depth 100 https://github.com/git/git.git，为了计算提交，我使用了这个命令 git log --oneline | wc -l。 （在工作中，我在 GitLab 服务器上观察到同样的事情，所以它不可能是 GitHub 工作方式的产物。）
有人知道这是怎么回事吗？深度值如何对应于实际下载的数据量？是我理解错了文档，还是有bug？
编辑：我为第二个回购添加了结果
--depth 表示克隆时要抓取的提交数。
默认情况下git下载所有分支的所有历史记录。 这意味着您的副本将包含所有历史记录，因此您将能够“切换”（签出）到您希望的任何提交。
添加 --depth 限制克隆的大小并仅检出最后 X 次提交
# Cloning a single branch with the following:
# clone specific branch and limit the history to last X commits
git clone --branch<...> --depth=<X>
How does the value for depth correspond to the actual amount of data downloaded? with the
--depthgit will only download the content corresponding to the commits in the given range so the size of the repo will raise when the value is larger
This would indicate that will equal the number of commits that will be fetched during the
并非总是如此，如果这些提交中的任何一个是合并（例如没有快进），您将获得超过 X 次提交。
如何清理二进制文件：
Rewriting git's history just to get rid of them seems like too much trouble
此工具可以为您完成：
https://rtyley.github.io/bfg-repo-cleaner
###
BFG Repo-Cleaneran alternative to git-filter-branch.
The BFG is a simpler, faster alternative to git-filter-branch for cleansing bad data out of your Git repository history:
*** Removing Crazy Big Files***
- Removing Passwords, Credentials & other Private data
Examples (from the official site) In all these examples bfg is an alias for java -jar bfg.jar.
# Delete all files named 'id_rsa' or 'id_dsa' :
bfg --delete-files id_{dsa,rsa} my-repo.git
作为
--depth 参数是指 Git 从每个起点开始 "walk" 的深度。正如您引用的文档中提到的那样，它还暗示 --single-branch，这简化了对此的讨论。这里的重点是遍历每个提交的 all parents，如果提交本身是一个合并，那么对于每个深度级别，它是不止一个提交。
假设我们有一个如下所示的提交图：
$ git log --graph --oneline master
* cf68824 profile: fix PATH with GOPATH
* 7c2376b profile: add Ruby gem support
* 95c8270 profile: set GOPATH
* 26a9cc3 vimrc: fiddle with netrw directory display
* 80b88a5 add ruby gems directory to path
[snip]
在这里，每个提交只有一个 parent。如果我们使用 --depth 3，我们将获取提示提交 cf68824，它的 parent 7c2376b 在深度 2，最后是 95c8270 在深度 3——然后我们停止了，提交了三个。
使用 Git 存储库 Git，但是：
$ git log --graph --oneline master
* 965798d1f2 Merge branch 'es/format-patch-range-diff-fix-fix'
|\
| * ac0edf1f46 range-diff: always pass at least minimal diff options
* | 5335669531 Merge branch 'en/rebase-consistency'
|\ \
| * | 6fcbad87d4 rebase docs: fix incorrect format of the section Behavioral Differences
* | | 7e75a63d74 RelNotes 2.20: drop spurious double quote
* | | 7a49e44465 RelNotes 2.20: clarify sentence
[snip]
对于 --depth 3，我们从 965798d1f2 开始，然后——对于深度 2——选取 both parents，ac0edf1f46 和 5335669531。为了添加深度 3 提交，我们选择了这两个提交的所有 parents。 ac0edf1f46的（单独的）parent在这里不可见，而5335669531的两个parent是（即6fcbad87d4和7e75a63d74） .要获取 ac0edf1f46 的 parent 的哈希 ID，我们可以使用：
$ git rev-parse ac0edf1f46^@
d8981c3f885ceaddfec0e545b0f995b96e5ec58f
所以这给了我们六个提交：master 的提示（当前是合并提交），该提交的两个 parent，其中一个 parent [=70] =]s，以及另一个 parent.
的两个 parents根据您 运行 克隆 Git 的确切时间，tip-most master 通常不是合并，但通常将合并作为其直接 parent，这样 --depth 2 通常会得到 3 次提交，因此 --depth 3 会得到 至少 5 次，这取决于两个 parent master 的尖端本身就是合并。
（将上面的 git rev-parse 输出与：
$ git rev-parse 965798d1f2^@
5335669531d83d7d6c905bcfca9b5f8e182dc4d4
ac0edf1f46fcf9b9f6f1156e555bdf740cd56c5f
例如。 ^@ 后缀表示 所有 parent 提交，但不是提交本身 。）