我知道这是可能的，因为我以前见过这种情况。Git使用哈希来标识版本是无关紧要的，因为存储库仍然有各种版本提交顺序的记录。
给定Git存储库的提交ID，如何获得与之对应的序号版本号(而不是特定文件)?给定存储库(不是特定文件)的版本号(如1、2等)，如何获得提交ID?
让你陷入麻烦的不是你不知道的事。这是你所知道的，但事实并非如此。我知道这是可能的，因为我以前见过这样的情况。
接近你想要的之类的东西的最好方法是使用git describe。详细信息请参见git describe文档。
Mercurial存储库确实有简单的序号，因为Mercurial的存储库结构是一个相对简单的仅追加数据库。Mercurial存储库中的每个提交也有独特的散列ID。您可以对-r使用这两种方法，因此-r 123获得提交#123，它可能具有哈希IDa123456(缩写)。这很方便……也是一个致命的陷阱。发生的情况是，Alice和Bob都克隆了某个特定的Mercurial存储库，该存储库中有1326个提交。它们的-r数字现在与所有这些提交完全对应，因为它们的克隆以相同的1326个提交以相同的顺序开始。
现在Alice向她的克隆添加了一些新的提交，可能是在一个新的分支或书签上。Bob也向他的克隆添加了一些新的提交。它们的新提交都得到相同的-r编号。
Bob和Alice开始聊天(可能是通过电子邮件，或者在Slack上，或者在饮水机旁的超级老派，或者无论他们在哪里工作都可以)。他们在-r 734中讨论了一些东西，他们都看到了相同的提交。他们想知道是否在-r 922中引入了一个bug，他们都查看了这个bug，并且再次看到了相同的提交。啊哈,他们认为,我们可以忽略那些大丑散列id,这些简单的顺序修改数量太容易得多,我们就使用它们!
最后,爱丽丝和鲍勃把他们提交公司主要Mercurial存储库。其中一个——假设是爱丽丝——在另一个前面推……所以在中央存储库中，Alice的提交保留了它们的编号，但是当Bob到达它时，Bob的提交在那里被重新编号。Bob提取(在之前或之后)并获得Alice的提交，使用新的和不同的数字。
从现在开始，Bob的修订号与其他人的不同步。Bob的-r 1328，在Bob的Mercurial存储库中，是Bob的commit。但是对于Alice和其他人来说，-r 1328是Alice的commit。Bob的提交直到-r 1331才开始。
在后面的对话中，Alice和Bob试图谈论他们的一个或两个新提交。他们完全混淆了，因为Bob认为Alice在谈论Bob的提交，而Alice认为Bob在谈论Alice的提交。
因为这些简单的线性-r数字不是通用的。Git从来没有犯过这个特别的错误(尽管Git犯了很多其他的错误)。不要尝试这样做;这是个坏主意。如果一个特定的提交非常重要，需要有一个通用的名称，给它一个标签。