如何在Git中找到分支的哈希值？

Question

给定本地/远程分支名称,我如何获得该分支指向的提交的哈希值？

Answer 1

命令git rev-parse是你的朋友,例如:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

......或远程跟踪分支:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

此命令通常非常有用,因为它可以解析指定分支名称的任何方法git,例如:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

...等

Answer 2

不要忘记，自 Git 2.19（2018 年第二季度）以来，Git 准备从 SHA1 哈希值过渡到 SHA2：请参阅“为什么 Git 不使用更现代的 SHA？ ”

在 Git 2.25（2020 年第一季度）中，git rev-parse进化并反映了可能的新哈希。

见提交fa26d5e，提交cf02be8，提交38ee26b，提交37ab8eb，提交0370b35，提交0253e12，提交45e2ef2，提交79b0edc，提交840624f，提交32a6707，提交440bf91，提交0b408ca，提交2eabd38（2019年10月28日），以及提交1bcef51，提交ecde49b（2019 年 10 月 5 日）作者：brian m。卡尔森 ( bk2204)。
^{（由Junio C gitsterHamano合并-- --在提交 28014c1 中, 2019 年 11 月 10 日）}

rev-parse: 添加一个--show-object-format选项

^{签字人：brian m. 卡尔森}

添加一个选项来打印用于输入、输出或存储的对象格式。
这允许 shell 脚本发现正在使用的哈希算法。

由于转换计划允许多个输入算法，记录我们可以为输入提供多个结果，以及结果可能采用的格式。
虽然我们现在不支持这一点，但尽早记录它意味着脚本作者可以在我们这样做时对他们的脚本进行未来验证。

该git rev-parse文档现在包括：

--show-object-format[=(storage|input|output)]:

显示用于存储在.git目录、输入或输出中的存储库的对象格式（哈希算法）。对于输入，可以打印多个算法，以空格分隔。如果未指定，则默认为“存储”。

使用 Git 2.29（2020 年第四季度），您可以确定必须使用哪种格式来读取分支（或任何其他对象）的哈希提交。

见提交e023ff0，提交4feb562，提交8a06d56，提交c49fe07，提交02a32db，提交ceaa4b3，提交eff45da，提交b5b46d7，提交c5aecfc，提交e74b606，提交439d3a1，提交6c2adf8，提交de5737c，提交e0a646e，提交6ff6a67，提交831279d，提交b6e5005，提交 287bb3a，提交 22f1824，提交 db00af9，提交7187eb1，提交98de0b2，提交a5587b8，提交66b6d43，提交2197f87，提交c0b65ea，提交d62607d，提交d482c23，提交866be6e，提交4bacb6d，提交252a4ee，提交368f3cb，提交abe3db1，提交08fbc5d，提交11b6961，提交9e3bd8a，提交d827bce ,提交 094a685（2020 年 7 月 29 日），作者是Brian m。卡尔森 ( bk2204)。
看约翰内斯·dscho辛德林( )提交 800e6a7 (2020 年 7 月 29 日)。
^{（由Junio C gitsterHamano合并-- --在提交 e0ad957 中，2020 年 8 月 11 日）}

docs: 添加文档 extensions.objectFormat

^{签字人：brian m. carlson
评论人：Eric Sunshine}

记录extensions.objectFormat配置设置。
警告用户不要自行修改。

git config现在包括在其手册页中：

extensions.objectFormat

指定要使用的哈希算法。

可接受的值为sha1和 > sha256。
如果未指定，sha1则假定。
除非core.repositoryFormatVersion是 1，否则指定此键是错误的。

请注意，此设置只能由git init或 设置git clone。
在初始化后尝试更改它是行不通的，并且会产生难以诊断的问题。

需要明确的是，在 Git 2.29（2020 年第四季度）中，最近添加的 SHA-256 支持在文档中被标记为实验性的。

请参阅Martin Ågren ( )提交的 ff233d8 (2020 年 8 月 16 日)。^{（由Junio C Hamano合并-- --在d1ff741 提交中，2020 年 8 月 24 日）}none
gitster

Documentation: 标记--object-format=sha256为实验

^{签字人：Martin Ågren}

在eff45daab8（“ repository：默认启用 SHA-256 支持”，2020 年 7 月 29 日，Git v2.29.0 --合并在第 6 批中列出）之后，Git 的 vanilla 版本使用户能够运行，例如，

git init --object-format=sha256  

并破解。
这可能是获得 SHA-256 世界经验的好方法，例如，查找错误

GIT_TEST_DEFAULT_HASH=sha256 make test  

没有发现。

但它确实是一个独立的世界：这样的 SHA-256 存储库将与（目前相当大的）SHA-1 存储库集完全分开。
原则上，跨边界交互是可能的，例如，通过“ diff+ apply”（或“ format-patch+ am”），但即使这样也有其局限性：在 SHA-1 存储库中应用 SHA-256 差异在简单情况下有效，但如果您需要求助-3，你运气不好。

同样，“ push+ pull”应该可以工作，但您实际上将主要与世界其他地方相抵消。当你初始化你的存储库时这可能没问题，在那之后几个月可能没问题，但可能有一天你开始后悔使用[git init --object-format=sha256](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>并且有把自己挖进一个相当深的洞里。

目前有一些主题正在讨论我们关于 SHA-256 的数据格式和协议，在某些情况下（midx 和提交图），我们正在考虑调整文件格式如何指示要使用的对象格式。

无论--object-format在我们的文档中提到的任何地方，让我们明确将其与“sha256”一起使用是实验性的。
如果我们稍后需要解释为什么我们无法处理我们在 2020 年生成的数据，我们可以随时指出我们在这里添加的这一段。

通过“include::” - 一个小简介，我们应该能够在整个文档中保持一致，并最终可以逐渐降低文本的严重性。
有一天，我们甚至可以用它来开始逐步淘汰--object-format=sha1，但我们不要超越自己......

也有extensions.objectFormat，不过只提到了三遍。我们在两次添加此新免责声明的地方，在第三个地方，我们已经有了“请勿编辑”警告。从那里，感兴趣的读者最终应该会找到我们在这里添加的这个新的。

因为GIT_DEFAULT_HASH提供了此功能的另一个入口点，所以也要记录它的实验性质。

git现在包括在其手册页中：

改为使用。默认值为“sha1”。这个变量是实验性的！见--object-format在git init。

object-format-disclaimer现在包括在其手册页中：

这个选项是实验性的！
SHA-256 支持是实验性的，仍处于早期阶段。

SHA-256 存储库通常无法 > 与“常规”SHA-1 存储库共享工作。
应该假设，例如，与 SHA-256 存储库相关的 Git 内部文件格式可能会以向后不兼容的方式更改。
仅--object-format=sha256用于测试目的。

相同的 Git 2.29（2020 年第四季度）确保“ git clone” ^（man）在从 SHA-1 存储库克隆时可以工作，而GIT_DEFAULT_HASH已经设置为使用 SHA-256。
在 2.29 之前，这导致了一个无法使用的存储库，该存储库声称是具有 SHA-1 对象和引用的 SHA-256 存储库。
这已得到纠正。

请参阅brian m 的提交 47ac970（2020 年 9 月 20 日）。卡尔森 ( bk2204)。
^{（由Junio C gitsterHamano合并-- --在提交 b28919c 中，2020 年 9 月 29 日）}

builtin/clone: 避免失败 GIT_DEFAULT_HASH

^{报告人：Matheus Tavares
签字人：brian m. 卡尔森}

如果用户克隆一个GIT_DEFAULT_HASH设置为“ sha256”的 SHA-1 存储库，那么我们最终会得到一个存储库格式版本为 0 但extensions.objectformat密钥设置为“ sha256”的存储库。
这是错误的（用户有一个 SHA-1 存储库）和不起作用（因为扩展不能在 v0 存储库中使用）。

发生这种情况是因为在克隆中，我们最初设置了存储库，然后根据远程端告诉我们它正在使用的内容更改其算法。
在这种情况下，我们最初将存储库设置为 SHA-256，然后在不清除扩展名的情况下重置存储库版本。

在这种情况下，我们总是可以设置扩展名，但这意味着我们的 SHA-1 存储库与旧版 Git 不兼容，即使没有理由不兼容。
而且我们也不希望最初将存储库初始化为 SHA-1，因为这意味着如果我们克隆一个空存储库，我们将无法遵守该GIT_DEFAULT_HASH变量，最终会得到一个 SHA-1 存储库，而不是一个 SHA-256 存储库。

这些都没有吸引力，所以让我们告诉存储库初始化代码，如果我们正在执行这样的重新初始化，如果是这样，如果我们使用 SHA-1，清除扩展名。
这可确保我们生成一个有效且功能齐全的存储库，并且不会破坏我们的任何其他用例。

Answer 3

散列存储在.git/refs/，例如.git/refs/heads/master

但是git rev-parse按照 Mark Longair 的建议以编程方式使用，因为它更安全。