git标签（tag）必须关联分支生命周期，否则仅打git tag v1.2.0无法保证该版本已测试、可部署或支持回滚；真实交付要求vx.y.z标签严格对应经验证的代码快照，如git flow中须在release分支合并至main后打标，github flow中则由ci在main合并后自动推断并打标。
语义化版本（SemVer）本身不强制绑定 Git 分支，但团队要实现可预测的发布节奏和自动化版本推断，就必须让 vX.Y.Z 标签与特定分支的合并动作形成稳定映射——否则标签就只是“贴纸”，不是版本契约。
为什么不能只靠 tag，必须关联分支生命周期？
仅打 git tag v1.2.0 不代表这个版本已通过测试、已部署、或具备回滚能力。真实交付中，v1.2.0 应该对应一个经过验证的代码快照，而这个快照必须来自明确的分支上下文：
- 如果从
feature/login直接打 tag，它可能含未合入develop的临时逻辑，也不含其他并行功能 - 如果从
develop打 tag，它通常未经 QA 验证，也不带构建产物一致性保障 - 只有从
release/1.2.0合并到main后立即打 tag，才能确保该版本：已冻结功能、已修复关键 bug、已通过冒烟测试、且后续所有 hotfix 都能基于它派生
主流分支模型中 SemVer 的落地位置
不同工作流对 vX.Y.Z 的生成时机和来源分支有明确差异，选错会导致版本号语义失效：
-
Git Flow：版本号在
release/*分支创建时就基本确定（如release/1.2.0），最终git tag v1.2.0必须在该分支成功合并到main后执行；hotfix/1.2.1必须从main拉出，修复后同时合并回main和develop，再打v1.2.1 -
GitHub Flow：没有
release分支，vX.Y.Z由 CI 在每次合并到main后自动计算——依赖提交类型（feat:→ 次版本号+1，fix:→ 修订号+1），tag 直接打在main对应 commit 上；main必须受保护，禁止直接 push -
GitLab Flow（环境分支型）：版本号通常绑定
production分支的合并事件；v1.2.0是当staging分支被合入production时打的 tag，而非合入前的预演分支
分支命名与版本号的硬性对应规则
为避免人工误操作导致版本混乱，建议在分支命名中显式携带版本信息，并用工具校验：
-
release/分支必须以release/vX.Y.Z或release/X.Y.Z命名（如release/v2.1.0），CI 可提取该字符串用于生成 tag -
hotfix/分支必须基于上一个main上的vX.Y.Ztag 派生，命名推荐hotfix/vX.Y.Z+1-xxx（如hotfix/v2.1.0+1-login-null），防止误认为是新功能 - 禁止使用模糊命名如
release/latest、hotfix/urgent—— 它们无法被自动化工具识别，也无法在 git log 中追溯版本边界
最常被忽略的一点：SemVer 的“兼容性承诺”只对 main（或 master）上打的 tag 有效。任何未合并到主干的分支上的 tag，都不应出现在 CHANGELOG 或 npm/GitHub Releases 页面里——否则用户安装 v1.2.0 却发现 API 行为与文档不符，问题根源往往就是 tag 打错了分支。
