Na vicat结构同步本身不会自动绑定Git分支，但如果要融入功能分支开发流程，必须让schema.xml文件的导出、提交与分支生命周期保持严格一致，禁止提交.nmodel二进制文件，所有数据库结构变更都应以带有清晰说明的schema.xml作为唯一信源。

Na vicat结构同步必须绑定Git分支生命周期

Na vicat本身并不能识别Git分支，但如果希望数据库变更真正纳入功能分支开发规范，核心就在于让.xml模型文件的提交与分支操作保持同步。不能只是在Na vicat里修改完模型后就直接发起PR，因为这样通常只是改动了本地的.nmodel二进制文件，Git无法准确识别任何数据库结构变化。

• 每次新建功能分支（如feat/user-profile-v2）之前，先从主干拉取最新的schema.xml，并导入到Na vicat模型工作区
• 所有字段新增、删除、索引调整和外键修改，都必须通过Na vicat模型编辑器完成，而不是直接执行ALTER TABLE
• 变更完成后，右键模型→Export Model to XML，覆盖同名schema.xml，再与业务代码一起执行git add和commit
• 在CI流水线中应增加校验：确认当前分支的schema.xml与目标环境数据库结构兼容，可通过Na vicat CLI或自定义diff脚本实现

正向工程同步必须限定在目标分支对应环境

在feat/invoice-report分支中导出的schema.xml，只能同步到对应的开发数据库（如dev_invoice），绝不能直接连接测试库或生产库。Na vicat不会自动帮你做环境隔离，它只会按照你当前选择的连接执行同步。

• 数据库连接别名必须包含明确的环境标识，例如DEV_MySQL_InvoiceDB、TEST_MySQL_InvoiceDB，以降低误操作风险
• 同步前务必再次确认连接右侧标签颜色，建议开发环境使用绿色、测试环境使用黄色、生产环境使用红色
• 预览SQL时要重点检查ALTER TABLE ... MODIFY COLUMN类语句，因为MySQL 8.0+在TEXT/BLOB字段类型变更时可能触发隐式锁表，而Na vicat默认不会提示
• 如果分支涉及多数据库联动，例如订单库与用户库的外键变更，需要手动拆分schema.xml为多个文件，并在CI中按照依赖顺序执行数据库同步

多人协作时.nmodel文件严禁直接合并

在团队协作场景中，假设两位开发者同时在feat/search-optimization分支上修改模型，只要各自导出schema.xml通常都没有问题。但如果有人绕过XML流程，直接提交修改后的search.nmodel二进制文件，那么Git在合并时只会提示“冲突”，根本无法看出究竟是谁删除了某个索引或调整了哪个字段。

• 团队应统一约定：.nmodel文件仅作为Na vicat本地缓存使用，不纳入Git追踪范围，并加入.gitignore
• 所有数据库结构变更都必须以schema.xml为唯一信源，且每次提交都要附带清晰的变更说明，例如“add fulltext index on product.name for search ranking”
• Na vicat On-Prem Server上的模型副本只适合作为初始版本分发，不应作为多人协同编辑中心，因为它不能解决冲突，反而更容易放大混乱
• 一旦发现XML与数据库实际结构不一致，应优先以XML为准重建开发环境数据库，而不是通过逆向工程反向覆盖XML

逆向工程仅用于验证，不能替代分支变更记录

上线前从生产库逆向生成一份prod_snapshot.xml是有价值的，但它本质上只是数据库结构快照，并不是变更日志。它无法告诉你某个字段是在上周哪次PR中由谁添加的，也无法帮助你回滚到某个功能分支的历史状态。

• 逆向工程生成的结果必须另存为prod-20260727.xml这类带时间戳的文件，而不要覆盖主schema.xml
• 在对比分支XML与生产快照时，应优先使用git diff schema.xml prod-20260727.xml，而不是完全依赖Na vicat图形化比对，因为后者通常不会显示字段注释的变化
• 如果发现生产库存在未提交的DDL，例如运维手动增加的监控字段，不要直接把它合并进功能分支的XML；应单独创建hotfix/missing-prod-column分支处理