git rev-parse --短头

Question

以下命令的作用是什么？：

git rev-parse --short HEAD

答案应包括：

1. 一个简短而中肯的答案，解释了这个命令的整体作用
2. rev解析的解释
3. --short 的解释
4. HEAD 的解释

Answer 1

git rev-parse --short都是一种方法：

• 验证它是否可以转换为可用于访问对象数据库的原始 20 字节 SHA-1
• 获取缩写 SHA（现在为 SHA1，稍后为 SHA2），尊重 core.abbrev 设置（正如我在此处提到的），默认情况下为 7 个字符。
  但如果 7 个字符不足以生成唯一的 SHA，git rev-parse 将生成正确的长度。

应用于 HEAD，它会返回当前签出提交的 SHA1 的简短版本（当 HEAd 分离时，这不一定是分支）

您可以在提交 e3ae4a8613151c93ffce78c674ac91c1ee34eef6, Aug. 2009, Git v1.6.5-rc0中看到它在 git/git 代码库本身中首次使用。

子串扩展表示法是一种 bashism，到目前为止我们还没有采用。
请改用“git rev-parse --short”，因为这也可以处理唯一缩写长度超过 7 个字符的情况。

所以而不是：

${sub1sha1:0:7}

使用：

sub1sha1_short=$(cd clone3/sub1 && git rev-parse --short HEAD)
$sub1sha1_short

您会发现它在2013 年 6 月的提交 e8f21ca，Git v1.8.4-rc0中用于 bash 提示符：

bash 提示：打印唯一的分离 HEAD 缩写对象名称

当根据$GIT_PS1_DESCRIBE环境变量描述分离的 HEAD 失败时，__git_ps1()运行 ' cut -c1-7 .git/HEAD' 以在提示中显示 7 个十六进制数字缩写的提交对象名称。
显然，这既不尊重core.abbrev也不产生唯一的对象名称。

通过使用“ git rev-parse --short HEAD”来修复此问题，并调整相应的测试以使用非标准的十六进制数字。

因为--short将计算 SHA 的最小长度是明确的，所以它应该是 git rev-parse 使用的最后一个选项。

请参阅提交 e3e0b93，也是 2013 年 6 月，Git v1.8.4-rc0

bash 提示：结合 'git rev-parse' 来分离头

当根据$GIT_PS1_DESCRIBE环境变量描述分离的 HEAD 失败时，__git_ps1()现在运行“ $(git rev-parse --short HEAD)”命令替换以获取缩写的分离的 HEAD 提交对象名称。
这会增加 fork() 子 shell 和 fork()+exec() 进程的开销git。

通过将此命令替换与“main”' git rev-parse' 执行相结合来避免这种开销，以获取目录和 co 的路径.git。
这意味着即使没有必要，我们也会查找缩写的提交对象名称，因为我们位于分支上或者可以描述分离的 HEAD。
不过，这并不重要，因为一旦’git rev-parse ”启动并运行以完成所有其他查询，查找缩写提交对象名称的额外开销就无法测量，因为它在噪音中丢失了。

然而，当我们位于未出生的分支上时，有一个警告，因为在这种情况下 HEAD 不指向有效的提交，因此对缩写提交对象名称的查询失败。
因此，“ --short HEAD”必须是“ git rev-parse”的最后一个选项，以便即使在未出生的分支上也能获取提示的所有其他必要信息。
此外，在这种情况下，并且仅在这种情况下，“ git rev-parse”显然不会输出包含缩写的提交对象名称的最后一行，因此我们必须注意仅在“ git rev-parse”退出且没有任何错误的情况下才解析它。