navicat 的 .sql 查询文件默认存于用户文档下的固定路径（windows：c:\users{用户名}\documents\navicat{数据库类型}\servers{连接名}\queries\；macos：/users/{用户名}/documents/navicat/{数据库类型}/servers{连接名}\queries/），该目录仅为本地缓存，不参与 git 版本控制；直接提交 queries 文件夹会导致文件名无意义、含私有元数据、路径冲突及内容不稳定等问题；正确做法是手动右键查询标签页→「另存为」至 git 仓库指定子目录（如 ./sql/queries/），使用语义化命名（如 get_active_users_by_date.sql），关闭自动时间戳注释，再执行 git add 和 git commit；团队须明确规范：“所有用于分析或上线的查询必须导出并提交，否则视为未完成。”
navicat 查询文件（.sql）本身不自动参与 git 版本控制，必须手动导出到 git 仓库路径下并提交——navicat 不监听查询编辑行为，也不会把“未保存的查询”或“临时标签页”纳入任何版本系统。
Navicat 的 .sql 查询文件默认存哪？
这些文件是 Navicat 自动保存的本地草稿，路径固定且与连接强绑定：
- Windows：
C:\Users\{用户名}\Documents\Navicat\{数据库类型}\Servers\{连接名}\queries\ - macOS：
/Users/{用户名}/Documents/Navicat/{数据库类型}/Servers/{连接名}/queries/
注意：该目录不是 Git 仓库，也不受 Navicat 版本控制功能管辖；它只是 Navicat 自己的缓存目录，重装或误删可能丢失。
为什么不能直接把 queries 文件夹加进 Git？
直接将 Navicat 自动生成的 queries 目录提交到 Git 会引发三类问题：
- 文件名无意义（如
query_12345.sql），无法体现业务意图 - 包含 Navicat 私有元数据（如
/* Navicat Premium */注释、时间戳、编码声明），每次打开都可能触发无意义 diff - 路径含连接名（如
localhost），不同人本地连接名不一致，导致路径冲突或 Git 忽略
更关键的是：Navicat 不保证该目录内容稳定——你删掉一个查询标签页，它可能立刻从磁盘删除对应文件，Git 会报 deleted by us 冲突。
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
正确的做法：手动导出 + 命名 + 提交
真正可维护的版本控制流程，必须绕过 queries 目录，走“主动导出 → 自定义命名 → 放入 Git 仓库 → 手动提交”路径：
- 在 Navicat 中右键查询标签页 → 「另存为」→ 选择你已初始化好的 Git 仓库子目录（如
./sql/queries/order_summary.sql） - 文件名用语义化命名（如
get_active_users_by_date.sql），避免数字编号或空格 - 导出前关闭 Navicat 设置里的「自动添加时间戳注释」（工具 → 选项 → SQL 编辑器 → 取消勾选）
- 导出后，在终端或 Git GUI 中执行
git add和git commit -m "add order summary query"
这个过程不可跳过。Navicat 永远不会替你做这一步，也没有后台任务监听查询变更。
团队协作时最易忽略的一环
不是路径配置，也不是分支命名，而是：没人明确负责把“刚写好的调试查询”导出为带业务含义的 .sql 文件并提交。结果就是 Git 里永远缺最新脚本，而同事只能靠截图或口头描述复现逻辑。建议在团队规范中写死一条：“所有用于分析或上线的查询，必须导出至 sql/queries/ 并提交，否则视为未完成。”
