把某个提交固定成标签，是发布流程里很常见的操作。实际操作时牵扯到“创建”和“推送”两个环节，很多人只在本地打了标签，以为别人也能看到，最后发布脚本拉取不到版本，才回头查远程仓库。下面按我平时处理的顺序说明。
在Git中，标签（Tag）用于将某个提交（Commit）固定为一个有意义的版本。如果只是想临时标记一个点，且不包含作者、日期等元信息，可以用轻量标签；如果要记录更完整的发布说明、签名信息，则应使用附注标签。判断依据很简单：执行 `git tag ` 创建的是轻量标签，而 `git tag -a -m "说明"` 创建的是附注标签。附注标签会额外存储打标签者的信息、时间以及备注，在 `git show` 时能看到这些内容，而轻量标签只显示指向的提交。
给当前分支的最新提交打标签，直接运行 `git tag v1.0.0` 即可。但更推荐使用附注标签：`git tag -a v1.0.0 -m "Release version 1.0.0"`。如果需要对历史提交打标签，需要先知道该提交的哈希值，例如 `git tag v0.9.0 `。打完标签后，用 `git tag` 可以列出所有标签，用 `git show v1.0.0` 可以查看标签详情。注意标签默认只会指向当前分支的HEAD，不会因为后续提交移动，除非使用 `-f` 强制覆盖已存在的标签。
先决定用哪种标签
在Git中，标签（Tag）用于将某个提交（Commit）固定为一个有意义的版本。如果只是想临时标记一个点，且不包含作者、日期等元信息，可以用轻量标签；如果要记录更完整的发布说明、签名信息，则应使用附注标签。判断依据很简单：执行 git tag 创建的是轻量标签，而 git tag -a -m "说明" 创建的是附注标签。附注标签会额外存储打标签者的信息、时间以及备注，在 git show 时能看到这些内容，而轻量标签只显示指向的提交。
这两种标签我都有用。临时标记测试环境或者想快速留个指针，用轻量标签就行；对外发布的版本，或者需要跨人协作的里程碑，建议用附注标签。附注标签里可以写清楚这个版本修了什么、和上个版本相比有什么变化，后续用git show一眼就能看到。如果你只是随手打了一个轻量标签，之后在CI/CD里想要生成发布说明，会发现能拿到的信息很少。
打标签的具体动作
在当前分支的最新提交上创建附注标签，我习惯这样写：
git tag -a v1.0.0 -m "Release version 1.0.0"这里的v1.0.0是标签名，-m后面的信息会存进标签对象里。如果只想临时标记，不带说明，可以这样：
git tag v1.0.0但注意，轻量标签和附注标签在未来的排查中差别很大。比如git show v1.0.0，对附注标签会显示打标签的人、时间和备注；对轻量标签只显示提交信息。所以“图省事”不一定划算。
如果这个版本对应的提交不是当前HEAD，需要先拿到提交哈希：
git tag v0.9.0 <commit-hash>这里<commit-hash>是完整的哈希或足够长的前缀。打完之后用git tag确认列表里出现新标签，用git show v1.0.0确认它指向哪个提交。
推送标签前要知道的规则
标签默认不会推送到远程仓库，这与分支不同。执行 git push 只会推送本地新的提交和分支，不会自动推送标签。如果直接运行 git push origin v1.0.0，会将该标签推送到远程；运行 git push origin --tags 会把所有本地未推送的标签一次性推送。风险在于，如果远程已有同名标签，推送会被拒绝。此时需要先删除远程标签（git push origin :refs/tags/v1.0.0），或者用 git push origin v1.0.0 --force 强制覆盖，但这样做会破坏其他协作者基于该标签的引用，应谨慎操作。
另外，如果你在本地的某个分支上创建了标签，但分支还没有推送，此时git push origin --tags不会帮你推送分支，它只会把标签推上去。远程仓库里会先有这个标签，但对应的提交可能不在任何分支上，这会让协作者拉取时找不到提交对象。所以稳妥的顺序是：先推送分支，再推送标签。
发布后要核对什么
标签推送成功后，我建议马上执行一次远程列表检查：
git ls-remote --tags origin看到类似refs/tags/v1.0.0的行，再对比末尾的哈希和本地git rev-parse v1.0.0的输出是否一致。如果一致，说明推送的是正确的提交。这一步尤其重要，因为发布脚本很可能以标签名作为拉取条件，标签指错位会导致部署了错误版本。
如果发现远程没有这个标签，可能是推送被拒绝，也可能是网络中断。先单独重推一次：git push origin v1.0.0，如果还是不行，检查远程分支保护规则或标签保护设置。有些Git平台默认禁止删除或强制更新标签，需要先在平台设置里调整。
如果以后要删除一个打错的标签，本地执行git tag -d v1.0.0，远程执行git push origin :refs/tags/v1.0.0。删除后记得提醒其他人不要再用旧标签做校验。
标签名和分支名别混淆
一个常见误区是使用 git push origin --tags 后，误以为会自动删除远程已经不存在的本地标签。实际上该命令只会推送新增标签，不会同步删除。要删除远程标签，需要单独执行 git push origin :refs/tags/。另一个坑是，标签名与分支名可以相同，但会造成混淆，例如 git tag main 会创建一个名为main的标签，而分支也叫main。此时 git show main 默认显示标签，而不是分支。为区分，建议标签名统一采用版本号格式（如v1.0.0），且不要与分支重名。
这个坑我见过不止一次。有人在仓库里创建一个名为test的分支，又打了一个名为test的标签，之后执行git show test，出来的不是分支头，而是标签内容。如果团队里有人习惯用git show来查看分支指针，会被误导。所以标签命名统一用v开头加版本号，分支名则沿用常见的main、dev、release/xxx，从命名上避开冲突。
把标签当作“提交的锚点”来用，创建时选对类型，推送时显式指定，推完立刻核对远程引用。这三步走完，标签引发的问题基本都能在发布前拦住。