不能直接提交，.ndm 文件是 ZIP 压缩包（含 XML/JSON/二进制资源），Git 无法 diff 和合并；应导出为 .sql 或 .json 等纯文本格式纳入 Git 管理，并禁止多人直接编辑同一 .ndm 文件。
Navicat Data Modeler 生成的 .ndm 文件能直接提交到 Git 吗？
不能直接提交，但可以——前提是确认它确实是纯文本格式且未加密。navicat data modeler 15+ 默认保存为 .ndm 文件，本质是 zip 压缩包（含 xml、json 和二进制资源），git 无法 diff，也无法解决合并冲突。
常见错误现象：git diff 显示 “binary file”、git log -p 看不到结构变更、团队协作时频繁覆盖模型文件。
- 验证方式：用
file model.ndm（Linux/macOS）或PowerShell Get-FileHash model.ndm -Algorithm MD5+ 对比大小，再尝试unzip -l model.ndm—— 如果能列出model.xml或schema.json，说明是 ZIP 封装 - Navicat Data Modeler 12 及更早版本可能输出纯 XML，可直接提交，但已基本淘汰
- 不要对
.ndm做git add -f强制跟踪，这会让 Git 放弃 diff 能力
如何导出可 Git 管理的模型源码？
必须通过 Navicat 的「导出」功能生成结构化文本，而非依赖原生 .ndm 文件。
- 菜单路径：
文件 → 导出 → 导出为 SQL 脚本或导出为 JSON/XML（取决于 Navicat 版本） - 推荐导出为
.sql：选中「生成 CREATE TABLE / ALTER TABLE 语句」，勾选「包含注释」「按字母序排列表」，避免因导出顺序不同导致无意义 diff - 若需保留逻辑模型（如实体关系、注释、样式），导出为
.json（Navicat 16+ 支持），文件名建议统一为model-schema.json - 导出时禁用「包含数据」和「包含索引/外键以外的 DDL」，否则每次导出会因统计信息或时间戳变化而产生脏 diff
如何让团队协作时不踩模型覆盖坑？
核心原则：禁止多人同时编辑同一 .ndm 文件；所有变更必须经由导出的文本文件走 Git 流程。
Lingxi · Webhook Dispatcher with GitHub API Fallback
下载
智能 Webhook 分发器，支持 GitHub API 回退机制。当 Git 推送失败时，自动路由至 GitHub Contents API。支持重试逻辑、del…
- 在项目根目录建
/db/model/目录，只放导出的schema.sql或model-schema.json，不放.ndm - 约定编辑流程：修改前先
git pull→ 用 Navicat 打开本地.ndm→ 调整模型 → 导出覆盖同名.sql或.json→git add && git commit -m "db: add user.email nullable" - 用
.gitattributes声明文本类型，避免 Git 误判：*schema.json diff=json<br>*.sql diff=sql
- SQL 导出文件建议加
-- git-hash: $(git rev-parse HEAD)注释行（手动或脚本注入），方便追溯模型与代码版本对应关系
为什么不用第三方工具自动转换 .ndm？
目前没有稳定、开源、维护活跃的工具能可靠解包并还原 .ndm 结构（尤其含视图、存储过程、样式信息时）。已有脚本（如 Python 解压后读取 XML）仅适用于简单模型，且 Navicat 私有字段（如 <diagram id="xxx"></diagram>）会随每次保存重生成，导致虚假 diff。
- 有人试过用
7z x model.ndm -o./tmp提取再 diff XML，结果发现modifiedTime、creatorId、randomId字段全变，diff 噪声远大于有效变更 - Navicat 官方不承诺
.ndm格式兼容性，15→16 升级后部分字段序列化方式变更，脚本极易失效 - 真正省事的做法不是“自动化转换”，而是把
.ndm当作本地编辑器缓存文件，只信任导出的 SQL/JSON —— 这和你不会把 Figma 的.fig提交到 Git，而是导出设计 token JSON 是一个道理
模型文件的文本化出口是人为控制点，不是技术障碍。谁负责导出、何时导出、导出哪些内容，比怎么破解 .ndm 更关键。
