轻量级标签是静态提交指针，非分支，不可切换开发；附注标签含元数据、支持签名与ci识别，正式发布必须使用。
轻量级标签不等于分支，别混淆两者用途
轻量级标签（git tag v1.0）只是一个指向某次提交的静态指针，没有历史、不能切换、不能提交——它不是分支。分支（如 main 或 feature/login）是可移动的、随新提交自动前进的引用，HEAD 可以指向它，你能在上面继续开发。
常见错误是把 git tag v1.0 当作“只读分支”来用：比如打完标签后切过去改代码，结果发现 git checkout v1.0 进入的是分离 HEAD 状态，后续提交不会归属任何分支，极易丢失。
- 轻量标签适合快速标记内部构建、CI 流水线中的临时快照（如
git tag ci-20260724-123） - 分支用于并行开发、功能隔离、长期维护（如
release/2.1分支可持续修复补丁） - 想基于某个标签继续工作？先用
git checkout -b hotfix-from-v1.0 v1.0创建新分支，而不是直接操作标签
为什么正式发布必须用附注标签，而不是轻量标签
轻量标签不带作者、时间、签名和消息，远程仓库拉取时无法验证来源，CI/CD 工具也难以提取版本元数据。附注标签（git tag -a v1.0.0 -m "Release 1.0.0"）会生成一个独立对象，包含完整签名链，Git 客户端能可靠识别其真实性。
如果你在 CI 中用 git describe --tags 获取当前版本号，轻量标签默认不参与计算（除非加 --always），而附注标签天然支持语义化版本推导。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 轻量标签无法被 GPG 签名：
git tag -s v1.0会报错，只有-a标志才支持-s - GitHub/GitLab 的 Release 页面只展示附注标签，轻量标签仅出现在 Tags 列表里，无下载、无描述、无变更日志
- 团队协作中，轻量标签容易被覆盖或误删（
git tag -f v1.0不提示警告），附注标签强制要求-f才能覆写
标签 + 分支配合的典型工作流
真实项目里，标签从不单独存在，它总依附于某个分支的稳定点。比如你在 main 分支上完成测试后打 v2.1.0 标签，这个动作本身不改变分支结构，但为后续维护提供了锚点。
后续热修复流程就依赖这种配合：从 v2.1.0 标签 checkout 出 hotfix/v2.1.1 分支 → 提交修复 → 合并回 main 和 develop → 再打新附注标签 v2.1.1。
- 不要在
develop分支上打发布标签——它不稳定；只在经过 QA 的main或release/*分支上操作 - 推送标签需显式执行：
git push origin v2.1.0或git push origin --tags；它不会随git push自动上传 - 删除远程轻量标签用
git push origin :refs/tags/v1.0，附注标签同理，但本地删除后建议立刻同步，避免他人误用
IDEA / VS Code 里标签和分支的显示差异容易误导人
VS Code 的 Git 插件和 IDEA 的 Git 工具栏，都会把标签和分支列在同一侧导航区，视觉上看起来地位相同。但点击标签名时，编辑器只是 checkout 到对应提交，并不会创建新分支——用户常误以为“点了就等于切换到了那个版本环境”，实际进入的是分离 HEAD。
真正需要复现某个版本时，应该右键标签 → “Create Branch from Tag…”（IDEA）或 “Checkout as new branch”（VS Code），否则所有修改都悬空。
- VS Code 状态栏显示的 “v1.0” 是当前 HEAD 所在提交的标签名，不是当前分支名；分支名显示在括号里，如 “main (v1.0)”
- IDEA 的 Git Log 面板中，标签图标（小卷标）和分支图标（箭头）样式不同，但默认不显示标签所属分支，需勾选 “Show tags in log” 并注意提交右侧的 ref 名称
- 本地有多个同名标签（比如误重复打
v1.0）时，GUI 工具可能只显示最新一个，命令行git tag -l v1.0才能确认是否冲突
