dolt_commit是唯一能固化模式变更进版本历史的存储过程，其他如dolt_checkout或dolt_branch仅调度分支而不保存schema变更；执行ddl后需显式调用dolt_commit才能生成新commit，空提交会失败。
dolt_commit 是唯一能真正把模式变更固化进版本历史的存储过程，其他如 dolt_checkout 或 dolt_branch 只管分支调度，不保存任何 schema 变更。
用 dolt_commit 提交 DDL 变更前必须先有真实改动
很多人调用 dolt_commit('add users table') 却发现没提交成功，因为 Dolt 不允许空提交。它只记录工作区（working set）里实际被修改的表结构或数据。
- 执行
CREATE TABLE、ALTER TABLE或DROP TABLE后，变更会暂存于工作区，但尚未进入版本历史 - 必须显式调用
dolt_commit才会生成新 commit，并写入当前分支的 HEAD - 如果只改了数据没改 schema，
dolt_commit仍会生效；但若既没改数据也没改 schema，调用会失败并报错error: no changes to commit
dolt_diff 要配合 --schema 参数才能看清结构差异
默认 dolt_diff() 只比对数据行变化，对字段增删、类型调整这类 DDL 变更完全不显示。容易误判“没改到”。
- 查表结构是否真变了：用
SELECT * FROM DOLT_DIFF('main', 'HEAD', 'employees', '--schema') - 注意参数顺序：
DOLT_DIFF(from_commit, to_commit, table_name, options)，--schema必须是最后一个参数 - 不加
--schema时，即使你刚执行了ALTER TABLE employees ADD COLUMN email VARCHAR(100)，dolt_diff也不会列出这行
分支操作不等于版本控制，dolt_branch 和 dolt_checkout 本身不产生版本
创建分支或切换分支只是移动指针，不会自动记录当前 schema 状态。新手常以为 CALL dolt_checkout('-b', 'feat-auth') 就完成了“版本隔离”，其实只是开了个空分支。
-
dolt_branch('feat-auth')仅创建分支引用，不复制当前 schema -
dolt_checkout('feat-auth')仅切换当前工作分支，也不触发任何持久化 - 真正形成可追溯的“版本”，必须在该分支上做 DDL/DML →
dolt_add（可选）→dolt_commit - 遗漏
dolt_commit是自动化脚本中最常见的断点，CI 流程里要加检查：提交后SELECT COUNT(*) FROM DOLT_LOG LIMIT 1确认 commit 已写入
Dolt 的版本控制逻辑紧贴 Git 模型，但所有“提交动作”必须由用户显式触发——没有隐式 save，也没有 auto-commit。哪怕你在 SQL 客户端里执行了 10 条 ALTER TABLE，只要没调 dolt_commit，这些变更就只存在于内存工作区，关掉连接就丢。
