有没有办法从远程 Git 存储库中仅检索一个特定提交，而不将其克隆到我的 PC 上？远程仓库的结构与我的完全相同，因此不会有任何冲突，但我不知道如何做到这一点，而且我不想克隆那个巨大的存储库。

我是git新手，有什么办法吗？

从 Git 版本 2.5+（2015 年第 2 季度）开始，获取单个提交（无需克隆完整存储库）实际上是可能的。

See commit 68ee628 by Fredrik Medley (moroten), 21 May 2015.
^{(Merged by Junio C Hamano -- gitster -- in commit a9d3493, 01 Jun 2015)}

您现在有了一个新的配置（在服务器端）

uploadpack.allowReachableSHA1InWant

Allow upload-pack接受请求可从任何引用提示访问的对象的获取请求。但请注意，计算对象可达性的计算成本很高。
默认为false.

如果将该服务器端配置与浅克隆结合起来（git fetch --depth=1），您可以请求一次提交（请参阅t/t5516-fetch-push.sh:

git fetch --depth=1 ../testrepo/.git <full-length SHA1>

您可以使用git cat-file命令查看提交已被获取：

git cat-file commit <full-length SHA1>

"git upload-pack“服务”git fetch“可以告诉服务 不在任何引用顶端的提交，只要它们是 可从 ref 到达，其中uploadpack.allowReachableSHA1InWant配置变量。

正如所指出的matt in 评论:

请注意，SHA 必须是完整的未缩写的 SHA，否则 Git 会声称找不到提交

完整的文档是：

upload-pack：可选择允许获取可到达的 sha1

With uploadpack.allowReachableSHA1InWant在服务器端设置的配置选项，“git fetch” 可以使用“want”行发出请求，该行命名尚未公布的对象（可能是从带外或从子模块指针获取的）。
只能从分支提示到达的对象，即广告分支和隐藏分支的并集transfer.hideRefs，将被处理。
请注意，必须回溯历史记录以检查可达性会产生相关成本。

当获取某个commit的内容时可以使用这个特性， sha1 是已知的，无需克隆整个 存储库，尤其是使用浅获取时.

有用的案例例如

• 包含历史记录中大文件的存储库，
• 仅获取子模块签出所需的数据，
• 当共享 sha1 而不告诉它属于哪个确切分支时以及在 Gerrit 中，如果您考虑的是提交而不是更改数字。
  （Gerrit 案已经通过allowTipSHA1InWant因为每个 Gerrit 更改都有一个参考。）

Git 2.6 (Q3 2015) will improve that model.
See commit 2bc31d1, commit cc118a6 (28 Jul 2015) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 824a0be, 19 Aug 2015)}

refs： 支持negative transfer.hideRefs

如果您使用隐藏引用层次结构transfer.hideRefs配置，以后无法覆盖该配置以“取消隐藏”它。
此补丁实现了“负”隐藏，这会导致匹配立即被标记为未隐藏，即使另一个匹配会隐藏它。
我们小心地以与配置机制提供给我们的方式相反的顺序应用匹配，因为这可以让我们通常的“最后一个获胜”配置优先级起作用（并且条目.git/config，例如，将覆盖/etc/gitconfig).

所以你现在可以这样做：

git config --system transfer.hideRefs refs/secret
git config transfer.hideRefs '!refs/secret/not-so-secret'

to hide refs/secret在所有存储库中，除了一个公共位 在一个特定的仓库中。

Git 2.7（2015 年 11 月/12 月）将再次改进：

See commit 948bfa2, commit 00b293e (05 Nov 2015), commit 78a766a, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015), commit 00b293e, commit 00b293e (05 Nov 2015), and commit 92cab49, commit 92cab49, commit 92cab49, commit 92cab49 (03 Nov 2015) by Lukas Fleischer (lfos).
Helped-by: Eric Sunshine (sunshineco).
^{(Merged by Jeff King -- peff -- in commit dbba85e, 20 Nov 2015)}

config.txt：记录语义hideRefs带有命名空间

目前还没有明确的定义transfer.hideRefs应该 设置命名空间时的行为。
解释一下hideRefs在这种情况下，前缀与剥离的名称匹配。就是这样hideRefs目前的模式是 在接收包中处理。

hideRefs：添加对匹配完整引用的支持

除了匹配剥离的参考之外，现在还可以添加hideRefs完整（未剥离）引用匹配的模式。
为了区分剥离匹配和完整匹配，这些新模式必须以扬抑符 (^).

因此新文档:

transfer.hideRefs:

如果正在使用命名空间，则在匹配之前，会从每个引用中删除命名空间前缀transfer.hiderefs模式。
例如，如果refs/heads/master指定于transfer.hideRefs和 当前的命名空间是foo, then refs/namespaces/foo/refs/heads/master广告中省略了但refs/heads/master and refs/namespaces/bar/refs/heads/master仍然被宣传为所谓的 “有”线。
为了在剥离之前匹配参考，添加^在...前面 参考名称。如果你结合! and ^, !必须首先指定。

R..提及在评论中配置uploadpack.allowAnySHA1InWant， 这使得upload-pack接受一个fetch请求任何对象。 （默认为false).

See 提交 f8edeaa（2016 年 11 月，Git v2.11.1）大卫·“诺瓦利斯”·特纳（novalis):

upload-pack：可选择允许获取任何 sha1

在我们的情况下进行可达性检查似乎有点愚蠢 信任用户可以访问存储库中的所有内容。

此外，它在分布式系统中很活跃——也许是一台服务器 为一名裁判做广告，但此后另一个裁判对该裁判进行了强制推送， 也许这两个 HTTP 请求最终定向到这些不同的 服务器。

With Git 2.34 (Q4 2021), "git upload-pack"^(man) which runs on the other side of git fetch^(man) forgot to take the ref namespaces into account when handling want-ref requests.

See commit 53a66ec, commit 3955140, commit bac01c6 (13 Aug 2021) by Kim Altintop (kim).
^{(Merged by Junio C Hamano -- gitster -- in commit 1ab13eb, 10 Sep 2021)}

docs：澄清transfer.hideRefs和命名空间的交互

^{Signed-off-by: Kim Altintop
Reviewed-by: Jonathan Tan}

展开文档中有关命名空间的部分transfer.hideRefs指出之间的细微差别upload-pack and receive-pack.

3955140 ("upload-pack.c：相对于命名空间对待want-ref”，2021-07-30，Git v2.34.0 --merge列于batch #5）教导upload-pack拒绝want-refs 表示隐藏引用，现在提到这一点。
需要澄清的是，隐藏引用的名称在任何时候都不会被泄露，但它指向的对象 id 可能会被泄露。

git config现在包含在其man page:

匹配之前的引用transfer.hiderefs模式。在 为了在剥离之前匹配参考，添加一个^在参考名称前面。如果 你结合! and ^, !必须首先指定。

git config现在包含在其man page:

广告中省略了。如果uploadpack.allowRefInWant已设定，upload-pack会治疗want-ref refs/heads/master在协议 v2 中fetch命令就像refs/namespaces/foo/refs/heads/master不存在。receive-pack另一方面，仍然会通告对象 id ref 指向但未提及其名称（所谓的“.have”线）。

With Git 2.39 (Q4 2022), "git receive-pack"^(man) used to use all the local refs as the boundary for checking connectivity of the data git push^(man) sent, but now it uses only the refs that it advertised to the pusher.
In a repository with the .hideRefs configuration, this reduces the resources needed to perform the check.

See commit bcec678, commit 5ff36c9, commit 8c1bc2a, commit 1e9f273, commit 05b9425, commit 9b67eb6, commit 5eeb9aa (17 Nov 2022) by Patrick Steinhardt (pks-t).
^{(Merged by Junio C Hamano -- gitster -- in commit f8828f9, 23 Nov 2022)}

revision：添加新参数以排除隐藏引用

^{Signed-off-by: Patrick Steinhardt
Signed-off-by: Taylor Blau}

用户可以选择通过以下方式隐藏 git-upload-pack(1)、git-receive-pack(1) 等中远程用户的引用transfer.hideRefs，但是现在没有一种简单的方法来获取所有可见或隐藏引用的列表。
不过，为了提高连接检查的性能，我们就需要这样做。

添加新选项--exclude-hidden=排除下一个伪引用中的任何隐藏引用，例如--all or --branches.

rev-list-options现在包含在其man page:

--exclude-hidden=[receive|uploadpack]

不要包含将被隐藏的引用git-receive-pack or git-upload-pack通过咨询适当的receive.hideRefs or uploadpack.hideRefs配置以及transfer.hideRefs (see git config）。该选项影响下一个伪引用选项--all or --glob并在处理后被清除。

And:

rev-parse: add --exclude-hidden= option

^{Signed-off-by: Patrick Steinhardt
Signed-off-by: Taylor Blau}

添加新的--exclude-hidden=选项与我们刚刚添加到 git-rev-list(1) 的选项类似。
给定一个部分名称uploadpack or receive作为参数，它使我们排除所有将被各自隐藏的引用$section.hideRefs配置。

git rev-parse现在包含在其man page:

--exclude-hidden=[receive|uploadpack]

不要包含将被隐藏的引用git-receive-pack or git-upload-pack通过咨询适当的receive.hideRefs or uploadpack.hideRefs配置以及transfer.hideRefs (see git config）。该选项影响下一个伪引用选项--all or --glob并在处理后被清除。