Navicat Data Modeler 本身不内置 Git，模型版本管理需依赖外部工具；必须导出为可 diff 的 SQL 脚本（如 schema.sql）并纳入 Git，禁用二进制 .ndm 文件；同步功能仅校准当前状态，非版本回放，生产环境须经 DBA 审核执行。
navicat data modeler 本身不内置 git 或类似版本控制系统，模型版本管理必须靠外部工具协同完成。 它不保存历史快照、不记录谁在何时改了哪张表，也不支持“撤销到上一版”这类操作。想真正管住模型演进，得把它当成代码来对待——导出、提交、比对、回滚，每一步都得手动介入。
导出模型为 SQL 脚本是版本控制的前提
Navicat Data Modeler 的核心输出是 SQL 文件（如 schema.sql），这是唯一能被 Git 追踪的稳定载体。直接提交 .ndm 文件没用：它是二进制或加密格式，Git 无法 diff，也不能合并。
- 使用
文件 → 导出 → SQL 文件，确保勾选“生成完整 DDL”，包括CREATE TABLE、ALTER TABLE、索引和约束 - 导出路径建议固定，例如
db/schema/20260727_v1.2_customers.sql，避免用默认名或桌面路径 - 若用“基于状态”策略，每次导出覆盖同一文件；若用“基于迁移”，则每次生成带序号的新文件，如
migration_003_add_order_status.sql
Navicat 同步功能 ≠ 版本控制，但可辅助验证
同步模型到数据库 和 同步数据库到模型 是双向校准动作，不是版本回放。它只反映当前差异，不记录过程。误点“同步到数据库”可能直接执行 DROP COLUMN，且无确认弹窗。
- 同步前务必先用
比较模型查看变更预览，重点关注标红的DROP类操作 - 生产环境严禁直接同步，应把生成的 SQL 拿到 Git 提交后，再由 DBA 手动审核执行
- Navicat 的
比较两个模型工作区可生成差异报告，但仅限本地比对，不能替代 Git 的分支对比能力
与 Git 协同时最容易踩的三个坑
很多团队卡在这一步：导出了 SQL，也提交了，但半年后发现根本没法还原。
-
.gitignore里漏掉了*.sql或写成了**/*.sql（后者会忽略子目录，而 Navicat 默认导出到多层嵌套路径） - 多人同时修改同一模型，导出的 SQL 文件名相同，Git 不报冲突，但实际内容已覆盖——必须约定命名规则，比如
schema_<date>_<author>.sql</author></date> - Navicat 导出的 SQL 默认含
USE database_name和连接信息，这些在 CI/CD 流水线中可能引发错误，需用脚本提前剥离或配置导出模板
真正的难点不在 Navicat 怎么点，而在于团队是否把模型当代码管：有没有统一的导出流程、有没有强制的提交信息规范、有没有人定期检查 SQL 是否真能重放成功。工具只是管道，堵点永远在人和流程上。
