生产环境必须用附注标签，因其包含作者、时间、签名及完整元数据，支持gpg验证和审计追溯；轻量标签仅是无凭证的commit指针，无法保障发布真实性和可验证性。
为什么生产环境必须用附注标签（git tag -a）而不是轻量标签
轻量标签只是个指向 commit 的指针，没作者、没时间、没签名，CI/CD 流水线或审计时无法验证“这个 v2.3.0 真的是运维团队打的，还是某人本地随手 git tag v2.3.0 生成的”。附注标签会存进 Git 对象库，带完整元数据，git show v2.3.0 能直接看到谁、什么时候、为什么打这个标签。生产环境出问题要回溯责任链，轻量标签等于没留凭证。
- 附注标签可被 GPG 签名：
git tag -s v2.3.0 -m "prod release: payment API stable"，签名后git verify-tag v2.3.0能验真伪 - CI 脚本常依赖
git describe --tags --exact-match判断当前是否在正式发布点，只有附注标签能被该命令稳定识别 - 轻量标签推送到远端后，
git ls-remote --tags origin可能只显示两次（带^{}后缀的 tag 对象引用），容易误判
打标签前必须确认的三个状态
很多线上事故源于“打了标签但代码其实没合并进主干”或“标签指向了 dev 分支的临时提交”。生产标签必须严格绑定到 main（或 master）分支上已合入、已测试、已批准的 commit。
- 先切到目标分支：
git checkout main && git pull origin main，确保本地main是最新且干净的 - 检查该 commit 是否已通过全部 CI 流水线：比如 GitHub Actions 显示
✅ build-and-test状态为 green，且 SHA 匹配git rev-parse HEAD - 确认没有未提交的本地改动：
git status --porcelain输出为空；若有输出，说明工作区不干净，不能打生产标签
git push origin --tags 不等于“安全推送”，要防覆盖和误删
默认 git push origin --tags 会把所有本地标签一股脑推上去，包括测试用的 v2.3.0-rc1、误操作的 v2.3.0-bak，甚至别人推过又删掉的旧标签。生产环境仓库通常配置了 protected tags 规则，但本地命令不会校验这些规则。
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
- 只推单个正式标签更可控：
git push origin v2.3.0，避免批量推送污染远端标签空间 - 如果远端已有同名标签，Git 默认拒绝覆盖；强行覆盖需
git push --force-with-lease origin :v2.3.0 && git push origin v2.3.0，但生产环境严禁 force push 标签——这会破坏其他人的构建缓存和部署记录 - 删除远程标签必须两步走：
git tag -d v2.3.0（删本地）→git push origin :refs/tags/v2.3.0（删远端），漏掉第一步会导致本地残留，下次--tags又推回去
用 git describe 做自动化版本号注入时的坑
很多构建脚本用 git describe --tags --always --dirty 生成版本字符串，比如 v2.3.0-5-gabc123-dirty。但这个命令的行为高度依赖当前所处分支和工作区状态，生产构建必须锁定上下文。
- 务必在
main分支上执行：git checkout main后再跑describe，否则可能返回v2.2.0-10-gdef456（来自 feature 分支的偏离数），误导发布系统 -
--dirty在 CI 环境中应禁用：CI 构建目录是干净克隆，不该有 dirty 状态；若出现，说明构建脚本意外修改了源码（如生成文件没加.gitignore） - 避免使用
--abbrev=0：它强制不缩写 commit ID，导致版本号极长（如v2.3.0-gabc123456789），某些容器 registry 或 Helm Chart name 字段长度有限制
生产环境的标签不是“打完就完”，而是整个发布链条的锚点。最容易被忽略的是：标签本身不可变，但标签名可以被重复使用——v2.3.0 如果被删过再重建，指向的 commit 就变了，所有基于该标签的部署记录和监控指标都会失效。所以一旦发布，标签名即成契约，不可重用、不可覆盖、不可解释性模糊。
