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

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

该命令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}

...等

哈希存储在.git/refs/，例如.git/refs/heads/master

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

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

借助Git 2.25（2020年第1季度），它git rev-parse得以发展并反映出了可能的新哈希值。

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

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

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

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

由于过渡计划允许使用多种输入算法，因此请记录我们可能会提供多种输入结果以及结果采用的格式。
尽管我们现在不支持此功能，但尽早对其进行记录意味着脚本作者可以在以后使用时对其脚本进行过时的验证。

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

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

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

使用Git 2.29（Q4 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，由brian m。提交094a685（2020年7月29日）。卡尔森（bk2204）。
看到Johannes Schindelin（dscho）提交800e6a7（2020年7月29日）。
^{（由Junio C gitsterHamano合并--在commit e0ad957中，2020年8月11日）}

docs：添加有关的文档 extensions.objectFormat

^{签字人：brian m。卡尔森
评论者：埃里克·阳光}

记录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（none 2020年8月16日）。
^{（通过合并JUNIOÇ滨野- gitster-在提交d1ff741 8月24日2020）}

Documentation：标记--object-format=sha256为实验性

^{签字人：马丁·奥格伦}

在eff45daab8（“ repository：默认情况下，默认启用SHA-256支持”，2020-07-29，Git v2.29.0-合并在批处理＃6中）之后，原始版本的Git使用户可以运行，例如，

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和commit-graph），我们正在考虑调整文件格式如何指示要使用的对象格式。

无论--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年第4季度）确保当从SHA-1存储库克隆一个克隆（而已设置为已使用SHA-256 ^）时，“ git clone” ^（man）将起作用GIT_DEFAULT_HASH。
在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时清除扩展名。
这可以确保我们产生一个有效的功能性存储库，并且不会破坏其他任何用例。