一旦触及并行更改的主题，您就会触及配置管理领域。有很多模式，有自己的社区(http://www.cmcrossroads.com/)这些工具不是用于版本管理（svn/git），而是用于支持配置管理（模式），如clearcase。（完全不同的区域）。
在这种情况下，它仍然是一个简单的情况，您会发现它有一些限制和一些手动工作以及一些列表。
我正在考虑的场景更能描述理想的解决方案：多个开发人员在同一个代码库上工作，多个测试环境，多个验收环境，多个生产验收环境，可能在世界各地。
如果您想更专业一些：
a） 写下你遇到的所有配置项的列表，这可能是WordPress代码本身、来自外部的插件、内容、元数据，并决定你想对其中哪些进行某种“管理”，哪些是重要的。
b） 描述可能发生的工作流，例如修复会发生什么，正在开发的新内容会发生什么，在什么情况下您会更改自己的内容，这叫什么，是谁做的，谁是它的所有者，例如新帖子或新插件。
c） 对于并行工作，首先描述您要管理的CI，确定流程是否总是从开发到生产，或者是否真的需要以两种方式完成所有这一切。
d） 对于（a）下的每种CI类型，请编写解决方案。E、 对于所有文本（或导出的文本，如php文件，但也包括XML文件中的纯文本），合并是可能的。这确实没有问题，但您需要一个好的合并工具。e、 g.使用ClearCase，您将以3种方式合并以下情况：1）琐碎的合并：它将自动执行这些操作2）非琐碎的自动操作：它将自动执行这些操作，但您需要进行检查3）非琐碎的非自动操作：这是一个冲突，例如，在1行上进行了多个更改。非琐碎的部分是您需要手动处理的最小部分，一个好的合并工具将引导您完成这项工作，例如clearcase中的合并工具（它也进行单词合并，并且您可以链接其他特定文件类型的商业或非商业合并）。此外，如果您在（a）项下确定了只应复制的文件，则其行为将不会被合并，而只是以一种方式复制，在不进行合并的情况下覆盖另一个版本（例如，未修改的插件）。这些类型中的许多可能具有不同的行为。但写下CI之间的关系，
然后，对于非基于文本的合并，您需要决定如何处理它们，例如在两个位置更改的图像。你可以在这里决定生产总是有偏好的（至少我是这么认为的），这使它变得简单。
所以要解决这个问题，您需要一个支持不同流的版本管理工具。每个流将代表一个部分。（这可能非常复杂，取决于您的需要，但在这种情况下，我认为它非常简单）。
如果您现在可以在WordPress安装下管理这些流，并将其与数据库内容同步，等等。。。然后，您可以在CM/版本控制工具中执行合并，然后将其导出回其他环境。
事情是。。。你需要先把这个写下来。这不是技术黑客。这是配置管理的默认模式，所以这里也没什么奇怪的，但您需要把它写下来。例如，您可能会发现，安装的插件在数据库中使用其他环境中不同的数据进行更改，因此您需要有一个额外的过程来解决这个问题。
从技术上讲，几乎总是一切皆有可能检查http://www.cmcrossroads.com/forums 对于复杂度高出几十倍或数百倍的场景，尽管始终使用相同的方法和相同的CM模式集。
简而言之：在其下放置一个版本管理层，自动化合并和处理冲突，然后在目标环境中导入。想一个适合这里的流程策略，然后写下来。执行微小的位CM管理。这将是专业的解决方案，否则安装一些数据库复制黑客，脚本等。。。
