我想你已经提出了两个问题，并把它们混合在一起，也许还加上了第三个问题：
1.为什么我得到的（带注解的）标签散列与某些现有的（带注解的）标签散列不同？
1.为什么带注解的标记有自己的哈希ID，与它们标记的提交的哈希ID分开？
1.给定一个可能有注解也可能没有注解的标记，我如何获得目标提交的哈希ID？
问题3的答案很简单：使用git rev-parse并使用正确的语法：

git rev-parse refs/tags/v1.2^{commit}

例如，将找到标记v1.2的提交目标的哈希ID。在大多数情况下，您可以省略refs/tags/部分。注意，^必须从DOS风格的CMD.EXE中引用出来（例如，将其加倍），但在大多数Unix风格的shell中，不需要引用。（这里的主要例外是tcsh，它的左大括号需要引用。）
问题1和问题2的答案是相互交织的：annotated 标签是任何带有注解、文本信息或签名的标签，是一个实际的内部Git对象，存储在Git的所有对象数据库中。创建一个新的带注解标签会创建一个新对象，并且一个新对象必须总是获得一个新的、从未使用过的哈希ID。1为了帮助确保这一点，Git会在每个这样的标签对象中添加您的姓名、电子邮件地址和当前日期和时间。
实际的带注解的标记对象包含目标对象的哈希ID，以及目标对象的类型。由于带注解的标记对象可以指向四种对象类型中的任何一种--包括其他带注解的标记对象--Git必须解析^{commit}后缀，方法是重复遍历标记对象，直到到达某个最终的结束点：提交、树或blob对象。如果最终对象不是提交，则^{commit}后缀会导致git rev-parse生成错误消息。
更简单的语法：

<tag-name>^{}

(e.g.，v1.2^{}）告诉Git重复解析带注解的标签--Git文档称之为 peeling 标签，指的是一次剥一层洋葱皮的想法--但当它到达最终目标对象时，它只是停止并产生那个哈希ID，而不管对象类型如何。
1通过pigeonhole principle，我们知道如果输入空间足够大，这在数学上是不可能的，但实际上它工作得很好。