如何检查 Git 提交是否属于某个标签

简介

在这个实验中，你将学习如何确定某个特定的 Git 提交是否包含在项目的任何标签中。这是一项很有价值的技能，有助于你了解哪些版本包含了特定的更改。

通过实践练习，你将使用 git tag --contains 命令来识别与给定提交关联的标签，并探索 git describe 用于检查标签的功能。你还将使用未打标签的提交来测试这些方法，以巩固你的理解。

Skills Graph

运行 git tag --contains 提交

在这一步中，你将学习如何使用 git tag --contains 命令来查找哪些标签包含特定的提交。当你想知道项目的哪些版本包含了特定的更改时，这个命令非常有用。

首先，确保你位于项目目录中。打开终端并导航到 my-time-machine 目录：

cd ~/project/my-time-machine

现在，让我们创建几个提交和标签来进行操作。我们将添加一个新文件并进行提交：

echo "Another message for the future" > message2.txt
git add message2.txt
git commit -m "Add a second message"

你应该会看到类似以下的输出：

[master <commit-hash>] Add a second message
 1 file changed, 1 insertion(+)
 create mode 100644 message2.txt

现在，让我们为这个提交添加一个标签。我们将其命名为 v1.0：

git tag v1.0

这个命令不会产生任何输出，但它已经创建了一个指向最新提交的标签。

让我们再进行一次没有标签的提交：

echo "A third message" > message3.txt
git add message3.txt
git commit -m "Add a third message"

你应该会看到类似以下的输出：

[master <commit-hash>] Add a third message
 1 file changed, 1 insertion(+)
 create mode 100644 message3.txt

现在我们有两个提交和一个标签。让我们使用 git log --oneline 来查看提交历史：

git log --oneline

你应该会看到类似以下的内容（提交哈希会有所不同）：

<commit-hash> (HEAD -> master) Add a third message
<commit-hash> (tag: v1.0) Add a second message
<commit-hash> Send a message to the future

注意，v1.0 标签与“Add a second message”提交相关联。

现在，让我们找出哪些标签包含“Add a second message”提交。我们需要这个提交的哈希值。从 git log --oneline 的输出中，复制 (tag: v1.0) 旁边的提交哈希。

将 <commit-hash> 替换为你复制的实际哈希值，然后运行以下命令：

git tag --contains <commit-hash>

你应该会在输出中看到 v1.0，因为这个标签直接指向该提交。

现在，让我们尝试找出哪些标签包含第一个提交（“Send a message to the future”）。从 git log --oneline 中复制该提交的哈希值。

将 <first-commit-hash> 替换为实际的哈希值并运行：

git tag --contains <first-commit-hash>

你应该仍然会在输出中看到 v1.0。这是因为 v1.0 所在的提交是第一个提交的后代。--contains 标志会检查指定的提交是否是标签所指向的提交的祖先。

当你需要确定软件的哪些版本包含特定的 bug 修复或功能时，这个命令非常有用。

使用 git describe 检查标签

在这一步中，我们将探索 git describe 命令。该命令用于查找从某个提交可到达的最近标签。它特别适用于为提交生成人类可读的名称，尤其是那些没有直接打标签的提交。

确保你仍然位于 ~/project/my-time-machine 目录中。

首先，让我们不带任何参数运行 git describe 命令：

git describe

由于我们的最新提交没有打标签，git describe 会查找最近的标签，然后告知从该标签之后进行了多少次提交，并提供最新提交哈希的简短版本。你应该会看到类似以下的输出：

v1.0-1-g<commit-hash>

让我们来解析一下这个输出：

• v1.0：这是当前提交的最近祖先标签。
• 1：这表示在 v1.0 标签和当前提交之间有 1 次提交。
• g<commit-hash>：g 代表“git”，<commit-hash> 是当前提交的简短唯一标识符。

这种格式对于识别项目的特定构建或版本非常有用，即使它们与标签不完全对应。

现在，让我们尝试在带有 v1.0 标签的提交上运行 git describe 命令。我们需要“Add a second message”提交的哈希值。你可以从 git log --oneline 中获取该值。

将 <commit-hash-of-v1.0> 替换为实际的哈希值并运行：

git describe <commit-hash-of-v1.0>

这次，输出应该简单地为：

v1.0

这是因为指定的提交直接被标记为 v1.0。当提交本身被打标签时，git describe 只会输出标签名称。

git describe 命令是理解提交和标签之间关系的强大工具，它提供了一种简洁的方式，根据提交与最近标签的接近程度来命名提交。

测试未打标签的提交

在这一步中，我们将进一步探索 git describe 对未直接打标签的提交的处理方式。这将加深你对它如何查找最近标签的理解。

确保你位于 ~/project/my-time-machine 目录中。

目前，在 v1.0 标签之后有一个提交。让我们再进行一次提交：

echo "Yet another message" > message4.txt
git add message4.txt
git commit -m "Add a fourth message"

你应该会看到类似以下的输出：

[master <commit-hash>] Add a fourth message
 1 file changed, 1 insertion(+)
 create mode 100644 message4.txt

现在，让我们再次运行 git describe 命令：

git describe

这次，输出应该类似于：

v1.0-2-g<commit-hash>

注意，v1.0 和提交哈希之间的数字现在是 2。这是因为自 v1.0 标签创建以来，master 分支上现在有两个提交。git describe 会正确计算从打标签的提交到当前提交的提交数量。

这种行为在持续集成和部署管道中非常有用，在这些场景中，你可能希望根据最新标签和自该标签以来的提交数量自动为构建生成版本名称。

让我们再尝试一件事。我们将创建一个新分支，并在该分支上进行一次提交。

git checkout -b feature/new-feature
echo "Feature file" > feature.txt
git add feature.txt
git commit -m "Add feature file"

你应该会看到类似以下的输出：

Switched to a new branch 'feature/new-feature'
[feature/new-feature <commit-hash>] Add feature file
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

现在，在这个新分支上运行 git describe 命令：

git describe

输出仍然会基于 v1.0 标签，但提交计数和哈希会不同：

v1.0-3-g<commit-hash>

即使我们处于不同的分支，git describe 仍然会找到最近可到达的标签，在这种情况下是 v1.0。提交计数 3 反映了从 v1.0 标签到 feature/new-feature 分支上当前提交的提交数量（master 分支上的两个提交加上特性分支上的一个提交）。

这展示了 git describe 在不同分支上的工作方式，它总是在提交历史中找到最近的标签。

总结

在本次实验中，我们学习了如何使用两种主要方法来检查一个 Git 提交是否属于某个标签。首先，我们探索了 git tag --contains <commit-hash> 命令，该命令可以直接列出包含指定提交的所有标签。这对于识别哪些版本或发行版包含了特定更改特别有用。我们通过创建提交和标签，然后使用 git log --oneline 获取提交哈希，再使用 git tag --contains 进行查询来进行了实践。

其次，我们简要提及了使用 git describe 作为将提交与标签关联起来的另一种方法，不过在本文中并未详细介绍具体步骤。本次实验还包括测试未打标签的提交这一步骤，这加深了我们对这些命令在提交未关联任何标签时的行为的理解。总体而言，本次实验让你在使用 Git 命令来梳理和理解项目历史中提交与标签之间的关系方面获得了实践经验。