Orici Asked: 2020-09-18 23:47:54 +0800 CST 2020-09-18 23:47:54 +0800 CST 2020-09-18 23:47:54 +0800 CST Git 中的标签有什么用？ 772 我知道标签存在，但我从未使用过它们，我还没有遇到任何使用它们的人，它们是用来做什么的？ 从Git 文档中的内容来看，这是一种创建消息历史记录的方法，与提交历史记录平行，仅标记最重要的更改，是吗？它有更多用途吗？ git 5 Answers Voted Best Answer Pablo Lozano 2020-09-19T00:54:06+08:002020-09-19T00:54:06+08:00 从字面上看，标签意味着标签。 每次提交时，都会创建一个类型的唯一标识符0dc20efa9ec36cefd67dcb832d9b01b7531c3a33，但是即使您发表评论说“此提交是 D-day 的生产版本”，查找起来也不是一件容易的事情，因此您可以创建一个标签帮助您找到它或快速恢复它。如果您当时创建了一个类型为v1.0.0的标签，您可以随时执行 agit checkout v1.0.0并且您将获得原样的代码。 当你移动到一个标签时，它就像移动到一个分支，但是处于分离模式：你不能修改代码和提交，除非你创建一个分支，因为你拥有的是一个快照，一个给定时间的代码快照。 此外，提交通常会将代码中的更改作为注释：新功能、错误补丁、美学更改……等等。标签可以包含关于部署的注释信息，自上一版本以来的更改列表......此外，标签本身已经可以让您了解（如果您使用semver）可能发生的更改以及向后兼容的水平。 ffflabs 2020-09-19T10:41:53+08:002020-09-19T10:41:53+08:00 除了无可挑剔的 Pablo 的回答之外，应该注意的是，当您在包注册表中发布库时（在 node 的情况下为 npmjs，在 PHP 的情况下为 packagist），它不适合使用您的人每次安装时都会带上#master 分支的库。 相反，您的库将有一个显式声明版本的清单（node.json 为 package.json，PHP 为 composer.json）。该版本与存储库标签相关联。 当有人安装您的库时，他们可以要求特定版本（例如 0.9.2），这与标签相关联，因为这个想法是，如果您要求特定版本，您收到的代码总是相同的。 包注册表通常会缓存库的版本，因此当有人安装它时，他们不必访问 GitHub（这会限制带宽）。此缓存允许注册表保留有限范围的版本，如果他们必须缓存您所做的每个提交，这将是不切实际的。 作为副作用，以这种方式发布的标签允许您继续修改主分支，而不必担心破坏上次看到它时正在工作的东西。也就是说：如果您的应用程序部署流程不是将分支而是将标签部署到生产环境，那么您不会通过向分支添加代码来损害生产环境。 值得注意的是，标签存在于与分支不同的层次结构中。分支旨在生成新功能或补丁，并最终与 master 重新集成。一个标签并不打算与其他标签或分支进行交互。出于同样的原因，您可以拥有一百万个标签，并且管理您的存储库不会增加难度。但是，如果您管理两打分支机构，它将变得难以管理。 Javi Mollá 2020-09-19T00:14:34+08:002020-09-19T00:14:34+08:00 它们用于留下记录，特定版本的标记。它们是在您发布版本（v0.1、v1.0、v2.2 等）时制作的，以便您可以返回到该版本，以防您必须测试该版本中发生的任何功能或错误 JackNavaRow 2020-11-17T07:40:40+08:002020-11-17T07:40:40+08:00 Tag 被应用为 GitFlow 的工作方法，想法是有以下分支 Master：主分支 HotFix：分支修复服务器上的问题 开发：为开发创建的分支 特征：您添加的新特征的名称示例（order_purchase） 当您有一组开发人员，他们都在开发不同的功能时，您必须将开发的所有内容交付给客户端（这称为发布），一旦功能在开发中统一并通过测试，它们就会被添加到master 分支，生成一个新标签。 标签比你想象的更常见如果你在 JavaScript 中工作，你会注意到package.json有类似@angular/cli的东西： "@angular/cli": "v7.1.0", 什么意思，把“ angular/cli”中标签为“ v7.1.0”的存储库带给我 如果您想知道如何下载标签，我邀请您阅读从 git 存储库下载特定标签 Mario Rojas 2020-09-20T14:35:27+08:002020-09-20T14:35:27+08:00 要冻结代码的最终版本，例如，如果您发布了 1.0 版，您可以生成一个标签并让用户下载该版本。 如果在标签代码中发现错误，则必须创建一个新分支来纠正它，稍后将其发布并重复标签循环。
从字面上看，标签意味着标签。
每次提交时，都会创建一个类型的唯一标识符
0dc20efa9ec36cefd67dcb832d9b01b7531c3a33，但是即使您发表评论说“此提交是 D-day 的生产版本”，查找起来也不是一件容易的事情，因此您可以创建一个标签帮助您找到它或快速恢复它。如果您当时创建了一个类型为v1.0.0的标签，您可以随时执行 agit checkout v1.0.0并且您将获得原样的代码。当你移动到一个标签时，它就像移动到一个分支，但是处于分离模式：你不能修改代码和提交，除非你创建一个分支，因为你拥有的是一个快照，一个给定时间的代码快照。
此外，提交通常会将代码中的更改作为注释：新功能、错误补丁、美学更改……等等。标签可以包含关于部署的注释信息，自上一版本以来的更改列表......此外，标签本身已经可以让您了解（如果您使用semver）可能发生的更改以及向后兼容的水平。
除了无可挑剔的 Pablo 的回答之外，应该注意的是，当您在包注册表中发布库时（在 node 的情况下为 npmjs，在 PHP 的情况下为 packagist），它不适合使用您的人每次安装时都会带上#master 分支的库。
相反，您的库将有一个显式声明版本的清单（node.json 为 package.json，PHP 为 composer.json）。该版本与存储库标签相关联。
当有人安装您的库时，他们可以要求特定版本（例如 0.9.2），这与标签相关联，因为这个想法是，如果您要求特定版本，您收到的代码总是相同的。
包注册表通常会缓存库的版本，因此当有人安装它时，他们不必访问 GitHub（这会限制带宽）。此缓存允许注册表保留有限范围的版本，如果他们必须缓存您所做的每个提交，这将是不切实际的。
作为副作用，以这种方式发布的标签允许您继续修改主分支，而不必担心破坏上次看到它时正在工作的东西。也就是说：如果您的应用程序部署流程不是将分支而是将标签部署到生产环境，那么您不会通过向分支添加代码来损害生产环境。
值得注意的是，标签存在于与分支不同的层次结构中。分支旨在生成新功能或补丁，并最终与 master 重新集成。一个标签并不打算与其他标签或分支进行交互。出于同样的原因，您可以拥有一百万个标签，并且管理您的存储库不会增加难度。但是，如果您管理两打分支机构，它将变得难以管理。
它们用于留下记录，特定版本的标记。它们是在您发布版本（v0.1、v1.0、v2.2 等）时制作的，以便您可以返回到该版本，以防您必须测试该版本中发生的任何功能或错误
Tag 被应用为 GitFlow 的工作方法，想法是有以下分支
当您有一组开发人员，他们都在开发不同的功能时，您必须将开发的所有内容交付给客户端（这称为发布），一旦功能在开发中统一并通过测试，它们就会被添加到master 分支，生成一个新标签。
标签比你想象的更常见如果你在 JavaScript 中工作，你会注意到
package.json有类似@angular/cli的东西：什么意思，把“
angular/cli”中标签为“v7.1.0”的存储库带给我如果您想知道如何下载标签，我邀请您阅读从 git 存储库下载特定标签
要冻结代码的最终版本，例如，如果您发布了 1.0 版，您可以生成一个标签并让用户下载该版本。
如果在标签代码中发现错误，则必须创建一个新分支来纠正它，稍后将其发布并重复标签循环。