发布版本、拉基线、标记里程碑，都离不开 git tag：它给历史中的某次提交钉上一张不可变的名片。tag 和分支的区别一句话讲清——分支是会随提交前进的指针，tag 是永远钉在同一提交上的固定指针，所以 tag 可以理解为"不可修改的分支"。这篇按查看、创建、推送删除、检出四类整理常用命令，末尾附速查表，系统讲解见 Pro Git 的打标签一章。
1、查看标签
三个查看命令如下：
git tag # 列出所有标签
git tag -l 'v3.*' # 通配符过滤，只看 v3 系列
git tag -n5 # 列表同时显示每条标签的注释
通配符必须配合 -l（或 --list）使用，直接 git tag 'v3.*' 会被当成创建标签。想看某条标签指向的提交详情，用 git show v3.1.0——附注标签会连带显示打标签的人、时间与注释内容，基础用法也可参考 菜鸟教程的标签章节。
2、创建标签
Git 的标签分两种：附注标签（annotated）与轻量标签（lightweight），创建命令如下：
git tag -a v1.2 -m '发布 1.2 版本' # 附注标签：完整对象，带注释
git tag v1.2-rc # 轻量标签：只是一个指针
git tag -a v1.1 9c030a3 -m '补打' # 给历史提交补打标签
不带 -m 时会进入编辑器写注释。两种标签的取舍如下：
| 维度 | 附注标签 | 轻量标签 |
|---|---|---|
| 本质 | Git 数据库中的完整对象 | 仅指向提交的引用 |
| 携带信息 | 打标签者、邮箱、日期、注释 | 无 |
| 校验 | 可被校验，支持 GPG 签名 | 不可 |
| 适用场景 | 正式版本、产品基线 | 临时标记、私人备忘 |
官方建议正式发布一律用附注标签——出问题时"谁在何时打的这个版本"就是关键信息。给历史提交补打标签时，末尾带上那笔提交的哈希即可（如上例的 9c030a3），默认则是给当前最新提交打。
3、推送与删除
提交代码不会自动带上标签，需要单独推送：
git push origin v1.2 # 推送单个标签到远程
git push origin --tags # 一次推送全部本地标签
git tag -d v1.2-rc # 删除本地标签
git push origin --delete v1.2-rc # 删除远程标签
基线管理的常见节奏：基线拉出、打附注标签、push origin 标签名 同步给团队，之后的发布记录就以 tag 为准。
4、检出标签与分离头指针
切到某个标签查看代码，和切分支用法相同：
git checkout v1.2 # 检出标签，进入分离头指针状态
git switch -c hotfix v1.2 # 基于 v1.2 拉出修复分支（推荐写法）
检出标签后 Git 会提示进入分离头指针（detached HEAD）状态：此时可以看代码、可以编译，但如果直接提交，新提交不属于任何分支，除了完整的提交哈希外无处可寻，极易丢失。所以要修旧版本的 bug，正确姿势是从标签拉出一条新分支（如上例的 hotfix），修完再走正常合并流程。
5、速查表
五类动作浓缩一张表：
| 场景 | 命令 |
|---|---|
| 列出 / 过滤标签 | git tag / git tag -l 'v3.*' |
| 打正式版本标签 | git tag -a v1.2 -m '注释' |
| 给历史提交补打 | git tag -a v1.1 9c030a3 |
| 推送单个 / 全部 | git push origin v1.2 / --tags |
| 删除本地 / 远程 | git tag -d v1.2 / git push origin --delete v1.2 |
| 基于标签拉分支 | git switch -c hotfix v1.2 |
6、总结
tag 的心智模型是"钉死在提交上的固定指针"：正式发布用附注标签（-a 加 -m，可校验可签名），临时标记用轻量标签；标签不会随代码推送自动上传，记得 push origin --tags；检出标签进入分离头指针状态，只读不写，要改就从标签拉分支。对于维护多版本的产品团队，建议把"拉基线 → 打附注标签 → 推送 → 基于标签拉修复分支"固化成标准动作，配合此前的分支、stash、log 三篇速查，Git 日常操作就凑齐了整套手册，更多细节可查 官方 git-tag 文档。
