navicat 不内置 git/svn，需手动导出 sql 脚本并用 git 管理；因其内部用二进制格式缓存设计，无法自动追踪变更，必须将 ddl 当代码提交、命名规范、明确 commit 信息、按版本兼容性导出。
navicat 本身不内置 git 或 svn 等版本控制系统，但可通过外部集成实现数据库设计稿的版本化管理——关键在于把 sql 文件 当作源码来管，而不是指望 navicat 自动提交结构变更。
为什么不能直接“连上 Git”管理 Navicat 的设计稿？
Navicat 的对象设计器（如表、视图、存储过程）生成的修改操作，不会自动保存为可追踪的文本文件。它内部使用的是二进制或专有格式缓存设计状态，.ncx 或连接配置文件不包含完整 DDL，也无法 diff。你看到的“同步结构”“对比模型”功能，只是运行时比对，不是版本控制。
常见错误现象：
— 在 Navicat 里改完一张表，关掉再打开，发现“撤销”失效；
— 团队成员各自导出 CREATE TABLE 脚本，但没人统一提交、没人写 commit message；
— 某次误删字段后，从 Navicat 历史执行记录里翻不到原始定义。
真正可行的集成路径：用 Navicat 导出 + 手动 Git 管理 SQL 文件
这是目前最稳定、被大量团队验证的方式。核心逻辑是：把 Navicat 当作“DDL 编辑器 + 执行终端”，而非“版本库客户端”。
- 每次结构变更前，先用
工具 → 结构同步 → 生成 SQL 脚本（别选“立即执行”，勾选“保存到文件”） - 脚本命名建议含版本号和上下文，例如：
v20260424_user_profile_add_phone_notnull.mysql8.sql - 将该 SQL 文件放入 Git 仓库的
/migrations/目录，和应用代码同仓或独立仓均可 - 在 Git commit 中明确描述变更意图，例如：
feat(db): add phone column to users, required for SMS auth - 回滚时，不是靠 Navicat “撤回”，而是 checkout 上一个 commit，手动执行前序脚本
Navicat 配合 Git 的几个实操细节
容易踩的坑往往出现在环境适配和权限环节：
-
SQL 脚本兼容性必须显式指定目标数据库版本。MySQL 5.7 和 8.0 对JSON字段、DESCRIBE语法、默认字符集处理不同，导出时务必在导出设置 → 兼容模式中选择对应版本 -
navicat.ini或连接配置里若启用了密码加密（ENC(AES:...)），导出的脚本不含密码，但本地执行时需确保已配置好对应连接或手动补全凭证 - 视图、函数、存储过程的导出需单独勾选，Navicat 默认只导表结构；遗漏会导致 Git 仓库中缺失关键逻辑
- 多人协作时，避免直接在同一个 Navicat 连接下反复“结构同步”，容易覆盖他人尚未提交的 SQL 变更。应约定：谁改结构，谁负责生成、测试、提交脚本
AI 助手能帮你做什么？不能帮你做什么？
Navicat 17.x 新增的 AI 助手（接入 ChatGPT / Qwen 等）可以：
- 根据自然语言描述，生成符合 MySQL 8.0 语法的
ALTER TABLE语句 - 对比两个 SQL 文件差异，并用中文解释字段类型变化影响
- 把一段旧版 Oracle 的建表语句，转成 PostgreSQL 兼容写法
但它不能：
- 自动监听 Navicat 界面操作并生成 commit
- 把你在对象设计器里拖拽字段顺序的动作，映射为可逆的
MODIFY COLUMN语句 - 替代你做分支策略决策（比如 dev 分支是否允许直接改生产库结构）
真正的版本控制粒度，永远落在你是否愿意把每一次 CREATE、ALTER、DROP 都当作一行代码来对待——Navicat 是刀，Git 是鞘，而你得亲手把刀插进去。
