代码之家 › 专栏 › 技术社区 › minecraftplayer1234

Git标记也标记所有以前的提交

git-tag github git

minecraftplayer1234 · 技术社区 · 6 年前

目前,我正在尝试在github上提供我的lib。有两种版本: 0.1 和 0.2 .我知道 pip 可以通过git上的标记找到包版本,所以我考虑了标记它。

当我这样做时:

git add .
git commit -m "msg1"
git tag -a 0.1 -m "lib v0.1"
git push origin master --tag 0.1

第一次提交标记为0.1

但当我在代码中更改某些内容时,我的做法几乎是一样的:

git add .
git commit -m "msg2"
git tag -a 0.2 -m "lib v0.2"
git push origin master --tag 0.2

最后一次提交标记为0.2,但第一次提交标记为0.2和0.1。我做错什么了吗?还是应该这样?

@编辑。这是我的git上的外观:

首次提交:

第二次提交:

Releases 标签:

2 回复 | 直到 6 年前

torek 6 年前

TL;博士

一切都很好。

长的

GitHub试图向GitHub用户隐藏Git的许多复杂性。我认为这是一个错误。虽然Git是出了名的用户不友好(参见,例如。, "10 things I hate about Git" 或 xkcd #1597 ), 一些这种复杂性确实是必要的。 ^1.

在Git标签的情况下,要了解标签的一点是,任何一个标签都只是某些特定哈希ID的一个人类可读的名称。哈希ID是那些大而难看的数字,就像GitHub灰显和缩写的东西,几乎无法读取。在您的屏幕截图中,此处显示的两个 a89f1cc 和 31a6a2d 。

这些哈希ID是 真实的 Git对象的名称,即Git本身用于发现对象的内容。这些哈希ID本身是通过应用加密哈希生成的到内容,因此哈希ID是键值数据库的短(ish)键:给定键,该键保证对这些特定内容是唯一的, ^2. Git可以查找该值并获取整个内容。由于这两个哈希值不同,因此这两个对象也必然不同。如果这两个对象是相同的,那么这两个哈希值将是相同的。

对于带注释的标记对象,实际上有必要再深入一点:带注释标记的内容包括 目标对象 。这可以通过命令lineagain轻松完成,GitHub隐藏了详细信息,但命令行也不是那么清楚:

git rev-parse a89f1cc^{}

例如,将查找对象 a89f1cc ,检查它是否是带注释的标记对象,如果是,则跟踪它另外对象标记本身的名称。如果 a89f1cc 是其他类型的对象,后缀 ^{} 没有效果。我们还可以写:

git rev-parse a89f1cc^{commit}

将找到犯罪对象 a89f1cc 解决或产生错误,在这种特殊情况下,这就是我们想要的:这将为我们提供 a89f1cc 本身,如果它已经是一个提交,或生成犯罪其中 a89f1cc 如果解析为提交,则解析,否则出错。

对于使用该系统的用户来说,更实际的是,给定两个标记名,您只需使用名称 :

git rev-parse v0.1^{commit}

以及:

git rev-parse v0.2^{commit}

查找标记指向的提交。(有些炮弹可能需要在帽子周围加上某种引号 ^ 和/或支架 {...} 字符;这取决于您是使用bash、tcsh、PowerShell还是其他什么。您可能需要稍微调整这些命令行命令,以使shell满意。)

将两个标记哈希中的每一个解析为提交将告诉您哪个提交或提交两个不同的标记名称。可以为单个提交提供多个标记,但您没有这样做,因此您将得到两个不同的提交哈希。这些承诺就是 pip install 将从签出、生成和安装。

^1. Albert Einstein is often paraphrased as saying Everything should be made as simple as possible, but not simpler, 虽然 Wikiquote says he actually wrote It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.

^2. 这有点夸张,具体取决于您的Git版本。看见 Hash collision in git 有关详细信息。

如果您是Git用户,还需要了解更多信息:标记vs分支,以及提交图

如果您只想安装,以上内容可能就是您所关心的全部。然而,对于使用Git本身的人来说,还有另一件事需要从中学习。

我们在上面看到,通过 git rev-parse (大多数Git命令在适当的情况下都会在内部执行)的哈希ID。但truewell也是如此, 主要地 a的trueof 分支机构名称 喜欢 master 或 develop 。我们可以运行:

$ git rev-parse v2.16.0
e1c2c6b098dfb717a4a6ff7f3894d57343210a41

获取如下哈希ID,但我们也可以运行:

$ git rev-parse master
ccdcbd54c4475c2238b310f7113ab3075b5abc9c

并获取哈希ID。此哈希ID是(一个,单个!)提交名称 主人 积分。所有Git都是这样 参考文献: 分支名称、标记名称、远程跟踪名称,如 origin/master ,等等,都是 参考文献 ,以Git表示, 每个引用转换为一(1)个哈希ID。

分支名称的特殊之处在于改变随着时间的推移。它们现在存储一个哈希ID,然后在您运行 git commit ,某些分支名称存储 新的,不同的 散列ID。事实上,这就是分支增长的方式:您告诉Git您希望成为 在…上 一些分支,通过运行,例如:

git checkout master

之后 git status 表示 on branch master .这意味着什么 在分支上 是吗 git提交 将改变您的分支名称:Git将新 commit,它将获得一些新的、看起来随机的哈希ID,然后Git将存储该ID 新将的哈希ID提交到名称中 主人 。

其基本机制是特殊名称 HEAD (在所有大写字母中,尽管在Windows和Mac系统上进行大小写折叠,但通常可以使用所有小写字母)。吉特 附加单词 头 到分支名称 为了记住您要求Git加入哪个分支。

如果分支名称只有一个大写字母,我们可以这样画出来:

A <-B <-C   <-- master (HEAD)

也就是说 头 已附加到 主人 ,以及名称 主人 指向犯罪 C –它包含提交的哈希ID C 犯罪 C 本身包含早期提交的哈希ID B ,并提交 B 包含提交的哈希ID A 。

在我们的例子中,我们的存储库很小:它只有这三个提交。犯罪 A. 没有早期的承诺称之为 根提交 所以它没有指向任何地方。这显示了Git的工作原理:它使用名称 主人 要查找 现在的 犯罪 C ,然后使用提交的内容 C 要查找 C 的 父母亲 犯罪 B .内容 B 让Git查找 B 的父级 A. 和 A. 没有父级,因此现在操作停止:Git显示提交 C 然后 B 然后 A. ,然后停止。

换句话说,Git是有效的向后。

当你做出新的承诺时 D ,Git通过记录所有代码的快照创建此提交,记录早期提交的实际哈希ID C ,然后写出提交并获取其实际哈希ID(无论是什么)。Git然后使用 头 要知道如何将新哈希ID写入 主人 ,给出:

A <-B <-C <-D   <-- master (HEAD)

现在呢 主人 名称(指向)提交 D 。

同样,这也是树枝正常移动和生长的方式。之间的区别 分支机构名称 主人 以及 标记名称 v0.1 分支名称是 应该移动 应该随着时间的推移而改变 最后的 提交该分支–但标记名没有移动一旦您指定了一个标记名来指向某个特定的提交,它就会固定在那里:它会一直指向该提交。

从提交到提交的链接形式a 图表 ,正是这个提交图将Git粘合在一起。GitHub试图对您隐藏提交图。因为Git主要是关于graphmere的文件过来坐车吧——这是一种可怕的伤害。理解提交图对于使用Git至关重要。

Robin Green 6 年前

这只是基于github如何在其UI中显示标记的误解。当git在提交上显示标记时,这并不一定意味着提交是用该版本标记的。要查看github中的实际标记,可以单击“Releases”选项卡。