Blogs

Appearance

给发布节点打标记：git tag ​

tag 解决的是“这个提交很重要，我以后还要准确找到它”的问题。

最典型的场景就是版本发布。比如 v1.2.0、v2.0.0-beta.1 这种名字，本质上都是在给某个提交打一个更容易记住的别名。

什么时候用 ​

  • 一次正式发布要留下清晰的版本节点
  • 某个修复版本已经上线，后面可能需要快速回查
  • 需要给 CI、发布系统、变更记录一个稳定锚点

如果只是普通开发提交，不需要为了“看起来规范”给每次提交都打 tag。tag 应该留给真正有里程碑意义的节点。

轻量标签和附注标签 ​

Git 的 tag 常见有两种：

  • 轻量标签：更像给提交起了一个简单别名
  • 附注标签：除了名字，还会记录作者、时间、说明，更适合正式发布

我自己的习惯是：正式版本一律用附注标签。

场景 1：给当前提交打一个正式发布标签 ​

shell
git tag -a v1.2.0 -m "release: v1.2.0"

-a 表示创建附注标签，-m 是这次标签的说明。

如果你想先确认 tag 有没有打到预期提交上，可以执行：

shell
git show v1.2.0

场景 2：给历史上的某个提交补打标签 ​

先找到那个提交的 commit id，再执行：

shell
git tag -a v1.2.0 <commit-id> -m "release: v1.2.0"

这个场景在“代码早就上线了，但版本标签当时忘了打”时很常见。

场景 3：把本地 tag 推到远程 ​

只推一个：

shell
git push origin v1.2.0

把本地所有 tag 一次性推上去：

shell
git push origin --tags

如果团队里没有明确规范，我更倾向于单独推指定 tag，避免把本地试验性质的标签一起带上去。

场景 4：查看现有标签 ​

shell
git tag
git tag -n

git tag -n 会顺手把标签说明也带出来，查版本时更直观。

场景 5：删错了 tag ​

删除本地 tag ​

shell
git tag -d v1.2.0

删除远程 tag ​

shell
git push origin :refs/tags/v1.2.0

或者：

shell
git push --delete origin v1.2.0

和分支有什么区别 ​

  • 分支会继续向前移动
  • tag 通常固定指向某个提交，不会随着后续开发自动前进

所以分支适合表示“还在持续开发的一条线”，tag 适合表示“这里是一个确定的版本节点”。

常见坑 ​

  • 本地打了 tag 但没 push，结果别人根本看不到
  • 发布时用轻量标签，后面缺少说明信息，不方便追溯
  • 把 tag 当分支用，想让它跟着代码继续走，这就偏了
  • 发布标签打在错误提交上，后面查版本时会非常混乱