Navicat 16本身不支持SQL脚本版本控制，需借助Git等外部工具；必须统一导出方式、禁用时间戳注释、标准化格式并分离schema与data，才能实现可靠协同。
Navicat 16本身不管理SQL脚本版本，得靠Git等外部工具协同
navicat 16 没有内置分支、合并、冲突标记或提交历史功能。所谓“解决sql脚本冲突”，实际是把 navicat 导出的 .sql 文件当作普通文本交给 git 处理——工具只负责生成和执行，协调责任在人+流程。
常见错误现象：两人同时改同一张表结构，各自导出 users.sql 后直接 push，Git 报 merge conflict；或者还原时发现字段顺序/注释/默认值不一致，但查不到是谁改的、什么时候改的。
- 必须统一导出方式：所有人用「转储 SQL 文件」而非「备份数据库」，后者生成的是二进制
.psc，Git 无法 diff - 导出前固定设置：勾选「导出表结构」+「导出表数据」+「兼容 MySQL 5.7」（若目标环境是旧版）
- 禁用「自动添加时间戳注释」：Navicat 默认在文件头写
-- Dumped by Navicat ... on 2026-04-23 15:22:01，每次导出都变，Git 会误判为全量变更 - 用命令行导出更可控：比如
mysqldump -h host -u user -p --skip-set-charset --default-character-set=utf8mb4 hh-vue > users.sql，避免 GUI 设置遗漏
导出SQL时字段顺序/空行/注释不一致导致Git假冲突
Navicat 导出的 SQL 脚本格式不稳定：有时字段按字母序排，有时按建表顺序；有时带空行，有时不带；注释位置随机。Git 会把这些当成实质性差异，拉取时一堆红色冲突块，其实只是格式问题。
使用场景：团队约定每周一上午导出全库 DDL 到 /ddl/ 目录，用于 CI 检查表结构一致性。
- 强制标准化格式：用
sqlformat或pg_format（MySQL 兼容版）统一处理导出文件，例如：sqlformat --reindent --keywords upper users.sql > users_clean.sql - 导出时关闭「导出注释」和「导出字符集声明」：这些字段易受 Navicat 版本/系统 locale 影响，删掉后 Git diff 更干净
- 在
.gitattributes中加规则：*sql text eol=lf whitespace=strip，避免 Windows/Linux 换行符和尾部空格干扰 - 别把
INSERT语句和CREATE TABLE混在一个文件里——拆成schema/和data/两个目录，Git 处理小文件更准
如何让Navicat与Git工作流无缝衔接
关键不是让 Navicat “支持 Git”，而是让开发者的操作路径绕过 Navicat 的不可控环节。例如，有人习惯右键表 →「转储 SQL 文件」→ 直接保存到桌面 → 手动拖进 Git 仓库，这中间漏了编码检查、格式清理、权限确认三步，必然出问题。
性能影响：Navicat 导出大表时若勾选「导出数据」，单个 .sql 文件可能超 100MB，Git clone/pull 会卡死；而用 mysqldump --tab 导出为 CSV + SQL 结构，则 Git 只需跟踪轻量结构文件。
- 用 Git Hooks 预检：在
.git/hooks/pre-commit里加校验，比如grep -q "SET NAMES utf8mb4" *.sql || exit 1，确保所有 SQL 文件字符集声明一致 - Navicat 连接配置也纳入版本控制：把
connections.ncx（Navicat 16 连接配置文件）存进私有 Git 仓库，但需先用sed -i '/password/d' connections.ncx清除密码字段 - 还原操作不走 Navicat 界面：CI 流程中用
mysql -h dev -u ci_user hh-vue ，避免图形界面引入额外连接参数干扰 - 禁止直接在共享测试库上运行 Navicat 导出的脚本：先
git checkout main && git pull拉最新版，再执行，否则容易覆盖他人已提交的修改
多人同时修改同个SQL文件时，怎么定位真实变更点
Git 显示 CONFLICT (content): Merge conflict in init.sql，打开一看全是 ALTER TABLE 语句，但看不出谁加了字段、谁删了索引——因为 Navicat 导出的 DDL 是完整重建式（DROP TABLE IF EXISTS + CREATE TABLE），不是增量式变更。
容易踩的坑：有人为“省事”直接在 Navicat 查询窗口写 ALTER TABLE users ADD COLUMN status TINYINT DEFAULT 1;，然后手动复制到 init.sql，但没同步更新导出文件，导致 Git 记录和实际 DB 状态脱节。
- 所有 DDL 变更必须走「版本化迁移」：用
flyway或liquibase管理，Navicat 只作查看和验证工具，不参与变更落地 - Navicat 导出后立即执行
git diff --no-index /dev/null users.sql | grep "^+" | grep -E "(ADD|DROP|MODIFY)"，快速过滤出真正新增/删除的字段级操作 - 对关键表启用
SHOW CREATE TABLE users\G快照：定期导出到/snapshots/目录，和 Git 历史对照，确认 Navicat 导出是否丢失了 COMMENT 或 ENGINE 参数 - 别信 Navicat 的「SQL 预览」按钮：它只模拟同步逻辑，不反映真实导出内容，最终以实际生成的
.sql文件为准
Git 不知道哪行 SQL 是 Navicat 自动生成的，哪行是人工写的；它只认文本差异。想靠工具自动消解 SQL 冲突，本质是错把协作问题当技术问题来解。
