我已经发布了一个sqlite工具，它可以满足您的要求。它使用一个自定义的差异驱动程序，利用sqlite项目工具'sqldiff'， uuid作为主键，并去掉sqlite rowid。它仍然处于alpha阶段，所以反馈是非常感谢的。

Postgres和mysql比较棘手，因为二进制数据保存在多个文件中，即使您能够对其进行快照，也可能无效。

https://github.com/cannadayr/git-sqlite

使用像iBatis Migrations这样的工具(手动，短教程视频)，它允许您在项目的整个生命周期中对数据库所做的更改进行版本控制，而不是数据库本身。

这允许您有选择地将单个更改应用到不同的环境中，记录哪些更改在哪些环境中，创建脚本以应用从a到N的更改、回滚更改等等。

有一个伟大的项目叫做“教义下的移民”，就是为了这个目的而建立的。

它仍然处于alpha状态，是为php构建的。

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

我开始想一个非常简单的解决方案，不知道为什么我以前没有想到!!

复制数据库(包括模式和数据)。 在new-major-changes的分支中，只需更改项目配置以使用新的重复数据库。

这样我就可以切换分支，而不用担心数据库模式更改。

编辑:

复制，我的意思是用不同的名称创建另一个数据库(如my_db_2);不是去倾倒之类的东西。

我们曾经在一个标准的LAMP配置上运行一个社交网站。我们有一个活动服务器、测试服务器和开发服务器，以及本地开发人员机器。所有这些都使用GIT进行管理。

On each machine, we had the PHP files, but also the MySQL service, and a folder with Images that users would upload. The Live server grew to have some 100K (!) recurrent users, the dump was about 2GB (!), the Image folder was some 50GB (!). By the time that I left, our server was reaching the limit of its CPU, Ram, and most of all, the concurrent net connection limits (We even compiled our own version of network card driver to max out the server 'lol'). We could not (nor should you assume with your website) put 2GB of data and 50GB of images in GIT.

To manage all this under GIT easily, we would ignore the binary folders (the folders containing the Images) by inserting these folder paths into .gitignore. We also had a folder called SQL outside the Apache documentroot path. In that SQL folder, we would put our SQL files from the developers in incremental numberings (001.florianm.sql, 001.johns.sql, 002.florianm.sql, etc). These SQL files were managed by GIT as well. The first sql file would indeed contain a large set of DB schema. We don't add user-data in GIT (eg the records of the users table, or the comments table), but data like configs or topology or other site specific data, was maintained in the sql files (and hence by GIT). Mostly its the developers (who know the code best) that determine what and what is not maintained by GIT with regards to SQL schema and data.

When it got to a release, the administrator logs in onto the dev server, merges the live branch with all developers and needed branches on the dev machine to an update branch, and pushed it to the test server. On the test server, he checks if the updating process for the Live server is still valid, and in quick succession, points all traffic in Apache to a placeholder site, creates a DB dump, points the working directory from 'live' to 'update', executes all new sql files into mysql, and repoints the traffic back to the correct site. When all stakeholders agreed after reviewing the test server, the Administrator did the same thing from Test server to Live server. Afterwards, he merges the live branch on the production server, to the master branch accross all servers, and rebased all live branches. The developers were responsible themselves to rebase their branches, but they generally know what they are doing.

如果测试服务器上有问题，例如。合并有太多冲突，然后代码被恢复(将工作分支指向'live')， SQL文件永远不会执行。在执行sql文件时，这被认为是一个不可逆的操作。如果SQL文件不能正常工作，则使用Dump恢复DB(开发人员被告知，因为提供了测试不佳的SQL文件)。

今天，我们同时维护一个sql-up和sql-down文件夹，它们具有相同的文件名，开发人员必须测试这两个正在升级的sql文件是否可以同样降级。这最终可以用bash脚本来执行，但是如果有人一直监视升级过程，这是个好主意。

虽然不是很好，但还是可以控制的。希望这能让你深入了解一个真实的、实用的、相对高可用性的站点。也许它有点过时，但仍然被遵循。

以下是我在项目中尝试做的事情:

分离数据、模式和默认数据。

数据库配置存储在不受版本控制的配置文件中(.gitignore)

数据库默认值(用于设置新项目)是一个受版本控制的简单SQL文件。

对于数据库模式，在版本控制下创建数据库模式转储。

最常见的方法是使用包含SQL语句的更新脚本(ALTER Table..或更新)。你还需要在你的数据库中有一个地方来保存你的模式的当前版本)

看看其他大型开源数据库项目(piwik，或者你最喜欢的cms系统)，它们都使用updatescripts (1.sql,2.sql,3.sh,4.php.5.sql)

但这是一项非常耗时的工作，您必须创建并测试更新脚本，还需要运行一个通用的更新脚本来比较版本并运行所有必要的更新脚本。

所以理论上(这就是我正在寻找的)你可以 在每次更改后转储数据库模式(手动，conjob, git钩子(可能在提交之前)) (只有在一些非常特殊的情况下才创建更新脚本)

之后，在您的普通updatescript中(对于特殊情况，运行正常的updatescript)，然后比较模式(转储和当前数据库)，然后自动生成必要的ALTER语句。已经有一些工具可以做到这一点，但还没有找到一个好的工具。