Navicat 16 不支持 Git Tag 功能，所有标签操作必须在终端执行 git tag 命令；它仅可配合验证标签对应版本的 SQL 脚本是否正确执行或同步，无法识别、显示或管理 Git 标签。
Navicat 16 本身不支持 Git Tag 功能——它是一款数据库客户端工具，不是代码版本控制系统。你无法在 Navicat 界面里执行 git tag、git push origin v1.0.0 或查看标签历史。
所有 Git 标签操作必须在命令行（终端）或 Git GUI 工具（如 GitHub Desktop、GitKraken）中完成，Navicat 只能间接配合使用。
git tag 命令必须在终端里运行，不是 Navicat 的功能
- Navicat 没有内置 Git 集成，也不解析或操作 Git 仓库元数据
- 它可以连接数据库、导出 SQL、同步结构，但不会读取
.git目录，也无法识别v2.3.0标签对应哪次提交 - 即使你的数据库迁移脚本（如
migrations/20260901_add_user_index.sql）放在 Git 仓库里，打标签的动作仍需离开 Navicat，在项目根目录下操作
常见误操作：
- 在 Navicat 的「查询」窗口里输入
git tag v1.0.0→ 报错：未知命令（这是 SQL 编辑器，不是 shell） - 试图在 Navicat 的「工具」菜单里找「Tag」选项 → 不存在
如何真正用 git tag 标记数据库相关重大版本？
假设你用 Git 管理数据库变更脚本（推荐做法），流程是：
- 确保所有 SQL 脚本已提交到本地仓库，且当前分支（如
main）指向你要发布的状态 - 在终端中执行：
git checkout main git tag -a v2.3.0 -m "DB: add user_profiles table + index on email"
- 推送标签：
git push origin v2.3.0
- 此时 GitHub/GitLab 的 Releases 页面就会生成带时间戳、描述和自动 ZIP 包的正式发布
关键点：
- 标签描述（
-m参数）建议包含数据库变更要点，比如 “add constraint”, “drop legacy column”, “migrate users to new schema” - 不要用轻量标签（
git tag v2.3.0），附注标签才能保留作者、时间、消息，方便审计
Navicat 能配合做的唯一一件事：验证标签对应版本的数据库结构是否正确
- 检出标签对应代码：
git checkout v2.3.0
- 此时你的 SQL 迁移文件（如
schema_v2.3.0.sql）就是该版本的权威定义 - 在 Navicat 中执行该文件，或用「数据传输」「结构同步」比对目标库是否匹配
⚠️ 注意：Navicat 不会自动感知 v2.3.0 标签，你得手动切换 Git 分支/标签后再打开 Navicat —— 工具之间没有联动。
真正的协同点只在这里：Git 标签定义“哪个 SQL 是 v2.3.0”，Navicat 负责执行或校验那个 SQL。
标签不是界面按钮，而是你对一次完整、可复现、带说明的代码+数据库状态的郑重签名。最容易被忽略的是：很多人打了标签却没写描述，或忘了推送，导致 GitHub 上看不到 Release；更隐蔽的问题是，把标签打在了开发分支而非 main，结果线上部署时拉错代码。
