一年多前我问过这个问题，在这段时间里，我们为团队增加了更多的人员，并在WordPress中开发了更多的网站。我想了解一下我们的流程，以防对其他人有所帮助。
Git中的每件事都是我在问问题时正在做的，但最好指出这一点。使用Git不仅帮助我们提高了工作效率，而且还多次节省了我们的集体成本。
您是否曾经需要对场地进行重大结构改造，从客户处获得这些改造的批准，并始终对未经改造的版本进行小的更新？我们有，Git让我们做吧。描述这个设置可能会有点冗长，但最基本的是我们创建了一个新分支，将该分支拉到服务器上，并将一个子域附加到该分支。
Git也拯救了我们。它当然允许我们回滚更改，这很好，但它也允许我们带回文件的旧版本。这意味着，如果客户问：“还记得一年前网站的这一部分是如何工作的吗？我们能把它带回来吗？”，答案是肯定的——即使被问及的人一年前不在该项目中。
除此之外，这也意味着我们永远不会没有所需的文件。我们总是可以从任何机器上下载该站点的最新版本并开始进行更改。
使用Git部署我们的WordPress托管Media Temple, 我们真的很喜欢他们。他们不是最便宜的供应商，但他们的服务很好，服务器的配置也很好。默认情况下，还提供Git。这意味着我们可以将服务器设置为Git存储库，并以这种方式而不是使用SFTP进行更改。这也意味着在服务器上执行工作不会有被覆盖的危险（因为这些更改可以被合并并推回）。
因为我们使用BitBucket 作为我们的Git主机，这里需要做一些额外的工作。首先，我们使用.ssh/config files 这样我们就可以ssh sitename 要登录到我们的服务器（我们还使用passwordless SSH, 这使得这非常容易）。我们还确保始终使用ssh passphrases （Mac OS X通过allowing you to store your passphrase in Keychain.app). 最后，我们将a ForwardAgent行添加到。要从中提取的主机上的ssh/config条目。这意味着我们只需要BitBucket中每个人的SSH公钥，而不需要每个服务器的公钥。我们还确保.git 目录公共HTML目录上方的一个目录。
每个人都有自己的wp配置，因为我们都有自己的本地数据库用户名和密码，而且因为我们可以使用不同的名称和服务机制，所以我们每个人都有自己的wp配置文件。每一个都存储在Git中，名称如下wp-config-gavin.php, 当我们想使用该配置时symlink it收件人wp-config.php （Git使用.gitignore).
这也允许我们覆盖siteurl 中的选项wp_options 类似这样的数据库表：
define(\'WP_SITEURL\', \'http://sitename.localhost\');
define(\'WP_HOME\', \'http://sitename.localhost\');
这会阻止WordPress查看数据库中的服务器位置，意味着本地和服务器安装之间的位置没有奇怪的差异。
关于wp配置的最后一点说明。php文件：确保store them above the public HTML directory and make the permissions read only for the web user. 这在确保WordPress的安全方面起到了巨大的作用。
数据库问题最后是关键。
我必须接受的是，在使用WordPress时，没有好的方法“合并”数据库更改。相反，我们需要制定行为规则来解决这一问题。规则相当简单，迄今为止对我们很有帮助。
在开发过程中，只有一个人“拥有”网站。这个人通常会进行设置（把托管包放在一起，开始Basecamp项目，分割设计，诸如此类的事情）。一旦那个人达到了合理的程度，就会转储WordPress安装所需的数据库并将其放入Git中。从那时起，进行开发的每个人都使用该数据库转储，而所有者是唯一对数据库进行更改的人。
一旦站点构建进一步推进，站点就会被放在服务器上。从那时起，服务器的数据库就是规范的。每个人（包括所有者）都必须在服务器上进行所有数据库更改，并将更改向下拉以进行本地开发和测试。
这个过程并不完美。仍有可能有人需要在开发过程中本地更改WordPress后端，然后在生产中再次进行这些更改。然而，我们发现这种情况很少见，这个过程对我们来说相当有效。
