所以我即将添加另一个WP博客，但我希望将其置于版本控制之下。然后我开始思考，这将如何影响我目前的WP工作流程。基于我使用WP的有限经验，当WP开发团队推送更新时，我在管理控制面板中看到了一个指示。从这里我可以简单地点击按钮，然后这些更改就在幕后实现了。这种方法对于版本控制之外的单个WP实例非常好，但对于版本控制中的更多节点呢？
一些WP更新包括代码和模式更改，所以我不能简单地发布代码而不实现新的模式更改。我能想到的最好的办法是做以下事情：
- 本地化存储在版本控制中的当前WP版本
- 下载最新(稳定)的wp文件
- 提取到本地路径(在步骤1中创建)
- 差异更改(可选)
- 提交对版本控制的更改
- 登录到每台服务器
- 进入维护模式
- 提取最新更改
- 实现新的架构更改(？？？)
- 测试
- 退出维护模式
第9步让我措手不及。我是否从本地(新更新的)模式中进行模式转储，然后为每个服务器导入该模式(或者如果WP包含id，则使用提供的模式更改文件)。
有更好的方法吗？
----编辑：2014年1月1日----
经过进一步的考虑，我想知道是否应该建立某种类型的mysql复制？拥有一个具有读/写访问权限的节点，这样它就可以进行仅限于数据库的更改(即取消激活小部件)，但让其他服务器提供从只读mysql实例读取的博客内容，这些实例被复制到。这样，只有一个服务器正在进行更改，其他服务器将从中提取。在我的研究过程中，我注意到一些更改，如通过functions.php或style.css对子主题的更改，可以在版本控制中跟踪，但其他更改，如激活/取消激活小部件，则完全基于sql，这在版本控制中将无法跟踪。
有更好的方法吗？
- 不要触摸WP核心(您真的需要它吗？)
或
- 只破解核心一次，以便将WP核心的默认存储库的URL替换为您的，并在以后对您的存储库使用系统自动更新程序