私はかなり誇りに思っているセットアップを持っています、そしてそれは私のチームにとって非常にうまく機能します。
一般的な構造
インストール全体をgitで管理します。システムの更新、プラグインの追加/更新、テーマの追加/更新など、すべての変更は同じワークフローを通ります。変更はすぐにロールバックできます。gitosisを実行しているデプロイメントサーバー（古いP4デスクトップ）がありますが、githubまたはgitoliteを簡単に使用できます。gitでは、2つの「特別な」ブランチがmasterありますdevelop（以下で詳しく説明します）。実稼働サーバーとステージングサーバーはクラウドベースです。
開発環境
すべての開発者は、独自のマシンで独自の開発サーバーを実行します。データベースに関しては、ライブデータが必要になることはほとんど問題になりません。主にテーマの単体テストデータを使用します。それ以外の場合、エクスポートとインポートはほとんどのことをカバーします。DBピースが重要な場合は、レプリケーションをセットアップするか、オンデマンド同期のために何かをセットアップできます。最初にこの構造をセットアップしたとき、これが重要だと思ったので、これを行うためのツールのセットを書き始めましたが、驚いたことに、それらは本当に必要ではありませんでした。（注：それらは必要ではなかったので、それらを洗練したことはなかったので、シリアル化されたデータのドメインを置き換えるバグなどがあります）。
ステージング環境
コミットがdevelopブランチからgitosisにプッシュされると、ステージングサーバーに自動的にデプロイされます。ステージングデータベースは、運用データベースのスレーブです。
本番環境
コミットがmasterブランチのgitosisにプッシュされると、それは自動的に運用サーバーにデプロイされます。
wp-config.phpの問題
wp-config.phpサーバーごとに一意である必要がありますが、バージョン管理下に置いておく必要もあります。私の解決策は、を使用.gitignoreしてwp-config.php、ステージングバージョンとプロダクションバージョンを別の名前のファイルとして保存することでした。次に、各サーバーで、たとえばをシンボリックリンクしますwp-config.php -> wp-config-production.php。各ユーザーは、独自の（追跡されていない）wp-config.php設定を使用して、独自の資格情報で独自のDBを保持します。
その他の注意事項
私は驚異的で安価なRackspace Cloudを使用しています。これにより、ステージングサーバーと運用サーバーを同一に保つことができます。また、現在、WordPress内からサービスを制御できるようにするためにAPIを使用するプラグインを作成していますが、それは素晴らしいことです。
キャッシュディレクトリ、ファイルアップロードディレクトリなどはすべて.gitignoreに追加されます。必要に応じて、cronタスクを設定して、アップロードを定期的にチェックインし、gitosisにプッシュすることもできますが、それは私には必要ではないようです。
マスター/開発構造は、Vincent Driessenの分岐モデルを部分的に模倣するように設定されています。また、彼のgit拡張git-flowを使用しますが、これも強くお勧めします。
私は1年以上にわたって10人ほどの開発者がこの構造を使用してきましたが、一緒に仕事をすることは夢でした。信頼性が高く、安全で、高速で、機能的で俊敏なため、これ以上要求することはできません！