应使用附注标签而非轻量标签，即执行 git tag -a v1.2.0 -m "release: v1.2.0" 并立即 git push origin v1.2.0；CI 脚本需用 git describe --tags --exact-match 校验，构建时动态注入版本号，打错 tag 应先删远程再删本地，并通过 conventional-commits 和 standard-version 落地语义化版本。
Git tag 怎么打才不会和 CI/CD 冲突
直接用 git tag v1.2.0 打轻量标签，CI 流水线很可能读不到版本号——很多构建脚本（比如 GitHub Actions 的 GITHUB_REF）只认附注标签（annotated tag）。轻量标签没提交对象、没签名、不带消息，CI 工具常直接忽略。
- 一律用
git tag -a v1.2.0 -m "release: v1.2.0"，强制生成附注标签 - 打完立刻
git push origin v1.2.0，别只git push --tags——后者可能推错历史里的旧 tag - CI 脚本里用
git describe --tags --exact-match校验当前 commit 是否对应一个精确 tag，避免误把 dev 分支当 release 构建
版本号怎么从 Git tag 自动注入到代码里
硬编码 VERSION = "1.2.0" 是反模式。每次发版都要改源码，容易漏、易冲突、无法溯源。正确做法是构建时动态注入，且必须区分开发态和发布态。
- Python 项目：在
setup.py或pyproject.toml中用setuptools_scm，配置use_scm_version = {"version_scheme": "post-release"}，它会自动从最近 tag 算出1.2.0.post1这类开发版号 - Go 项目：编译时用
-ldflags "-X main.version=$(git describe --tags --always)"，但注意git describe在无 tag 的初始提交会失败，得加兜底逻辑 - 前端项目：Webpack 插件
git-revision-webpack-plugin可注入process.env.GIT_VERSION，但需确认打包环境有完整 .git 目录（Docker 构建常被删掉）
不小心打了错的 tag 怎么安全撤回
本地 tag 删了就行，但已推到远程的 tag 不能靠「覆盖」解决——Git 不允许强制覆盖已存在 tag，强行 git push -f origin v1.2.0 会失败或引发协作混乱。
- 先删远程：
git push origin :refs/tags/v1.2.0（注意冒号前有空格） - 再删本地：
git tag -d v1.2.0 - 如果别人已经拉过这个 tag，得同步通知，因为
git fetch --prune默认不清理已删除的远程 tag - 补救比预防成本高得多，建议在 CI 里加检查：
git ls-remote --tags origin | grep "v[0-9]"防止重复打同名 tag
语义化版本（SemVer）在 Git tag 里怎么落地
v1.2.0 看似规范，但 Git 本身不管语义。真正起作用的是团队约定和工具链配合——否则 v2.0.0 可能只是改了个按钮颜色。
- 用
conventional-commits规范提交信息，再配standard-version自动生成 tag 和 CHANGELOG，feat:提交触发次版本号（1.2.0 → 1.3.0），fix:触发修订号（1.2.0 → 1.2.1） - 预发布标签必须带横线：
v1.2.0-beta.1，不能写成v1.2.0beta1——后者会被npm version当作正式版处理 - CI 检查脚本里用
semverCLI 工具验证 tag 格式：semver -r "^([0-9]+)\.([0-9]+)\.([0-9]+)(?:-([0-9A-Za-z.-]+))?$" v1.2.0
v1.2.0 可能指向不同分支的提交；打 tag 前务必确认当前 HEAD 是目标 release commit，而不是 merge 后的临时状态。 
