前置き
Git Flowと共に見るインフラの完璧な姿
バージョン管理と公開作業の関係
WEB制作に限らず、あらゆるアプリケーション開発にとって、バージョン管理と公開（あるいは納品）作業は切り離すことのできない概念です。
特にWeb制作ではバージョン番号(0.0.0)が変更される本番公開の他にも、いくつかの「限定された公開範囲」での公開経て、最終的な一般公開へと終着します。
どのようなサーバーを用意して、どのように公開作業をするのか？Git Flowの運用を絡めて、紹介します。
サーバーのソースコードは、バージョン管理と完全に一致させる
ソースコード変更は、必ずバージョン管理側が先であるということが前提です。
「サーバーでファイルを削除してみたから、Gitでも削除しておこう」
というようなことは、禁忌中の禁忌です。
このルールを違反してしまうと、バージョン管理の価値を根底から崩してしまいます。
ですので、Gitのソースコードをサーバーにアップロードするのは、できる限り自動化することを目指します。
昨今では、GitHubに置かれたブランチ（リポジトリではなく）そのものをストレージとして扱い、公開するようなウェブサービスも存在します。
これらは、健全な労働環境とコストパフォーマンスを求めた最適化の答えであり、世界の動向はそちらに向いています。
WordPressは機能の設計（プラグイン等も含め）が、データベースサーバー、共有されたテーブルに依存します。
また、サイト仕様やコンテンツの大部分を「サーバー上で設計する」という思想に基づいて作られているため、バージョン管理との相性が非常に悪いです。
そのため、チーム内や後継者との仕様の共有も難しく、PHPという自由度の高すぎる環境も相まって、担当開発者一個人に強くロックインしてしまう傾向にあります。
よく、無料で万能であることが最大の長所として挙げられますが、その実態はバージョン管理やQAが行き届かず、コストのかかる課題やリスクを導入時にのみ隠蔽し、後工程（保守・納品先）に丸投げしているに過ぎません。
WordPressは、CMSとその概念の一般化で一世代を築いたことは間違いありません。しかし、偉業を称えつつも、その役目を終えた存在であると、弊社は捉えています。