时间戳

首页 > 解决方案 > 远程查找分支上的 git commit 和 tag 信息

git - 远程查找分支上的 git commit 和 tag 信息

问题描述

是否可以远程确定 SHA 值和 Git 标签，即无需克隆 git repo？

我想确定 repo 是否有 n 次提交，然后触发一个工作。但是，克隆每个 repo 或维护一个 repo 将非常耗时。

标签： git

解决方案

你可以得到一些你想要的信息git ls-remote。这会让您的 Git 调用其他 Git 并要求其他 Git 列出其分支和标签名称，以及相应的哈希 ID。

您的主题行要求：

分支上的 git 提交和标记信息

但这个短语格式不正确。“标签信息”，特别是——无论你用那个短语是什么意思——永远不会“在一个分支上”；至多，标签名称与分支名称一致，或者标记对象可从一个或多个分支名称访问。由于一个提交可以在数十个分支上，因此标签名称识别在1 个多个分支上的提交并不罕见。

分支名称是一个完整拼写形式以 : 开头的名称refs/heads/：例如，分支master是真的refs/heads/master。标记名称是一个完整拼写形式以refs/tags/: 开头的名称，例如，标记v2.1是真的refs/tags/v2.1。该git ls-remote命令让他们的 Git 告诉你的 Git 他们的全名——refs/heads/例如，他们的分支名称是他们的分支名称——以及他们相应的哈希 ID。

每个名称仅包含一个哈希 ID。两个不同的名称可以包含两个不同的哈希 ID，或相同的哈希 ID。

分支名称是受限制的：它们总是保存一些现有的有效提交的哈希 ID。标签名称通常包含带注释的标签对象的哈希 ID，而不是提交的哈希 ID。当标签名称包含标签对象的哈希 ID 时，您将获得两个输出行。以下是来自的输出片段git ls-remote：

274b9cc25322d9ee79aa8e6d4e86f0ffe5ced925        refs/heads/master
...
74d2a8cf12bf102a8cedaf66736503bb3fe88dfb        refs/tags/v2.2.0
b260d265e189728b26e50506ac6ffab6a7d588da        refs/tags/v2.2.0^{}
3fabc04268de1cec1628265810769e33dae44cd8        refs/tags/v2.2.0-rc0
4ace7ff4557350b7e0b57d024a2ea311b332e01d        refs/tags/v2.2.0-rc0^{}

这告诉我们他们的 Gitmaster标识了 commit 274b9cc25322d9ee79aa8e6d4e86f0ffe5ced925。他们的 Gitv2.2.0识别标签对象74d2a8cf12bf102a8cedaf66736503bb3fe88dfb，而标签对象又识别另一个对象，在这种情况下是b260d265e189728b26e50506ac6ffab6a7d588da.

仅凭此无法判断对象的类型b260d265e189728b26e50506ac6ffab6a7d588da是什么，但实际上它是一个提交。（要找出答案，我们让 Git 将对象传输到我们的 Git，然后使用git cat-file -t.）

我想确定回购是否发生了 n 次提交...

如果这里的n代表一个数字，你不能这样做：计算提交需要你有提交。

如果这里的n代表new，你就不能那么做。假设您发现他们现在有一个分支名称B来标识提交C1。明天，您查询他们的存储库并发现他们有分支名称B，但它现在标识提交C2。您可以知道分支名称已移动，但您不确定它是否“向前”移动以进行新的提交。它可能已经“向后”移动以丢弃提交，或者“横向”移动，以便一些旧的提交消失并且现在可以访问一些新的提交。

克隆每个 repo 或维护一个 repo 将非常耗时...

克隆存储库可能需要一段时间，具体取决于您的网络速度。但是，在大多数情况下，更新克隆非常快，特别是如果克隆是用--bareor制作的，--mirror因此没有要更新的工作树。因此，这通常是要走的路。

一些构建系统每次都进行新的克隆，但使用浅克隆来避免带入大多数对象。这可能是处理大型存储库的成功方法。

1我在这里使用分支上的短语，意思是提交可以从分支提示到达，由该分支名称标识。另一种描述方式是提交包含在分支中。有关此主题的更多信息，请参阅Think Like (a) Git。

推荐阅读