我正在做一个web应用程序，我需要为一些主要的更改做一个分支，事情是，这些更改需要更改数据库模式，所以我想把整个数据库放在git下。
我怎么做呢?是否有一个特定的文件夹，我可以保存在git存储库下?我怎么知道是哪个?我如何确定我放入了正确的文件夹?
我需要确定，因为这些更改是不向后兼容的;我可不能搞砸。
在我的例子中，数据库是PostgreSQL
编辑:
有人建议进行备份并将备份文件置于版本控制之下，而不是将数据库置于版本控制之下。说实话，我觉得这真的很难接受。
肯定有更好的办法。
更新:
好吧，没有更好的方法了，但我还是不太相信，所以我要稍微改变一下问题:
我想将整个数据库置于版本控制之下，我可以使用什么数据库引擎来将实际数据库置于版本控制之下，而不是转储?
sqlite是git友好的吗?
因为这只是开发环境，所以我可以选择任何我想要的数据库。
Edit2:
我真正想要的不是跟踪我的开发历史，而是能够从我的“新的根本性变化”分支切换到“当前稳定的分支”，并且能够用当前稳定的分支修复一些错误/问题等。这样，当我切换分支时，数据库就会自动地与我当前所在的分支兼容。 我不太关心实际数据。
当前回答
我们曾经在一个标准的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脚本来执行，但是如果有人一直监视升级过程，这是个好主意。
虽然不是很好，但还是可以控制的。希望这能让你深入了解一个真实的、实用的、相对高可用性的站点。也许它有点过时，但仍然被遵循。
其他回答
我们曾经在一个标准的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脚本来执行，但是如果有人一直监视升级过程，这是个好主意。
虽然不是很好，但还是可以控制的。希望这能让你深入了解一个真实的、实用的、相对高可用性的站点。也许它有点过时，但仍然被遵循。
我开始想一个非常简单的解决方案，不知道为什么我以前没有想到!!
复制数据库(包括模式和数据)。 在new-major-changes的分支中，只需更改项目配置以使用新的重复数据库。
这样我就可以切换分支，而不用担心数据库模式更改。
编辑:
复制，我的意思是用不同的名称创建另一个数据库(如my_db_2);不是去倾倒之类的东西。
使用版本控制的数据库，现在有几个这样的数据库。
https://www.dolthub.com/blog/2021-09-17-database-version-control/
这些产品没有在其他类型的数据库上应用版本控制——它们是自己的数据库引擎，支持版本控制操作。因此，您需要迁移到它们，或者在它们的基础上开始构建。
我编写了其中一个，DoltDB，它结合了MySQL和Git的接口。看看这里:
https://github.com/dolthub/dolt
这个问题基本上已经回答了，但我想用一个小建议来补充X-Istence和Dana the Sane的回答。
如果您需要具有一定粒度的修订控制，比如每天，那么您可以使用rdiff-backup之类的工具将表和模式的文本转储与增量备份结合起来。这样做的好处是，不存储每日备份的快照，而只存储与前一天的差异。
这样你就有了修订控制的优势，也不会浪费太多的空间。
在任何情况下，直接在频繁更改的大平面文件上使用git都不是一个好的解决方案。如果数据库变得太大，git在管理文件时会出现一些问题。
采用一个数据库转储，并对其进行版本控制。这样它就是一个平面文本文件。
我个人建议同时保留一个数据转储和一个模式转储。通过使用diff，可以相当容易地看到从一个修订到另一个修订的模式中发生了哪些变化。
如果您正在进行大的更改，那么您应该有一个用于进行新模式更改的辅助数据库，而不会触及旧数据库，因为正如您所说的，您正在进行一个分支。
