我正在改进适用于WordPress开发项目的git工作流。通常，在开发内容管理系统时，我会创建一个开发服务器（如http://dev.finalsitename.com），其中包含将在生产版本中使用的自定义帖子类型和分类法。这样，我的客户就可以开始将其内容添加到该站点。
当他们执行此任务时，我通常会构建外观和感觉以及将在我的本地主机环境中使用的自定义编程/插件。为了确保不覆盖他们的任何更新，通常我会拉下他们数据库的副本并替换我的数据库。但是，有时候我只需要跳到WP管理区域并更改设置或其他一些小的内容...
如果有多个开发人员在进行WordPress项目，则我们每个人都会对网站的版本进行（时间戳记）数据库转储，并将其包含在根目录中，然后再提交并将其本地分支推回远程存储库。这种方法的麻烦在于，数据库通常不同步，无法轻松确定要使用的数据库。
其他开发人员在保持数据库同步同时又允许多个开发人员（和客户/内容生产者）从事同一个项目时又做了什么？
Answers:
最简单的3个选项->
仅使用一个您都连接了很多备份的远程数据库。这样，您只需要担心文件而不是数据库。
使用WordPress中内置的导入和导出功能，并将其直接放入wp根目录中的版本控制中（例如在新文件夹中）。当然，这需要花费几分钟，但是它非常简单，您可以自动化它，但更重要的是它将成为版本控制的一部分。
使用自定义更新脚本来对实际数据库同步进行版本控制。老实说，我不知道您怎么用git来管理它，因为它只是一个脚本，并且并不真正知道发生了什么，我知道有第三方的工具可以免费商业化（http：// www。 liquibase.org/）。
如果您需要使数据库完全同步，即。模式和数据，则可以基于备份开发自定义版本控制系统。
或者，如果您要保留生产中的数据，但要改进其架构，则可以使用自定义解决方案（具有所有架构更改的版本文件），或者使用基于的概念的标准解决方案migration。您可以在以下stackoverflow线程中找到很多信息：跟踪数据库架构更改的机制。
如果这看起来非常明显，我很抱歉，但是如果所有人都需要具有相同结构的相同数据库副本，那么拥有一台办公室/中央SQL Server并使用它就没有意义吗？如果需要进行实验，请在本地克隆它，但将其保留为权威的事实上的标准，并对该服务器（仅该服务器）进行备份。
否则，当我在一个小组项目中工作时，我们将拥有不同内容的设置。该代码负责升级和迁移表结构，并且我们可以通过LAN访问彼此在本地计算机上运行的代码的本地安装，因此无需共享内容。
如果要输入内容，则可以在测试服务器上运行内容，然后可以将其导出并导入到实时服务器中，如果当前不存在实时实例，则可以直接迁移到生产服务器上。
如果在任何时候都需要将实时测试和WIP数据分开，则只需在存储库中使用实时，测试和开发分支