为什么数据库文件不建议提交：你提交的不是数据，是未来的麻烦

你有没有遇到过这种场景：项目刚起步，大家图省事，把本地的app.db（SQLite）、data.mv.db（H2）、甚至某个dump.sql一起丢进 Git。短期看起来很爽——拉下来就能跑、数据也现成。

但过不了多久，你会发现：仓库越来越大、合并越来越痛、线上问题越来越难复现，甚至还会在某一天突然意识到“我们把生产数据提交上去了”。

这篇文章想讲清楚一件事：数据库文件不是源代码，它更像“运行时产物”。把它提交到版本库，通常是在把不可控的状态带入协作系统。

1. Git 适合管理“可文本 diff 的历史”，不适合管理“不断变化的二进制状态”

Git 的强项是：代码是文本、差异清晰、合并可控、冲突可解决。你改了一个函数，Git 可以精确告诉你改了哪几行。

但数据库文件（尤其是 SQLite 这类单文件数据库）本质上是二进制结构。你往表里插入一行数据，可能导致多个页（page）被重写；你更新一个字段，可能触发页分裂、空洞回收、B-Tree 重平衡。

结果就是：

• 你改动很小，但 Git 看见的是“整个文件都变了”。
• 你想对比数据变化，但git diff基本无能为力。
• 你想做三方合并（3-way merge），Git 也做不了，最后只能二选一：保留谁的数据库文件？

这不是工