はじめに
目的
本書は「CMS×Git」をわかりやすく整理することを目的としています。CMS運用にGitを取り入れるメリットや、実際の連携方法、運用上の注意点を実例を交えて丁寧に説明します。
対象読者
- CMSを使っている開発者・運用者
- これからGitを使った運用を検討する担当者
専門的な前提知識は不要です。用語はできる限り噛み砕いて説明します。
本書で扱う内容（3つの軸）
- GitベースのヘッドレスCMS（例：Gitに直接コンテンツを置く仕組み）
- 既存CMS（特にWordPressやHubSpot）とGitを連携して運用する方法
- Gitと静的サイトを組み合わせたCMS的な運用（ビルドとデプロイの流れ）
読み方の目安
各章は独立して読めますが、順に読むと全体像がつかめます。まずは第2章でメリットを把握し、第3～5章で具体的な選択肢と手順を確認してください。
なぜ CMS と Git を連携するのか
はじめに
CMS と Git を連携すると、サイト運用がより安全で効率的になります。ここでは具体的な利点と導入時の注意点をやさしく説明します。
バージョン管理とロールバック
Git は変更履歴を記録します。いつ、誰が、どのファイルを変えたかが残るため、誤った変更があっても以前の状態に戻せます。例えば記事を誤って消しても復元できます。
複数人での安全な共同編集
ブランチとプルリクエスト（PR）を使うと、編集を分けて作業し、レビューを経てから本番に反映できます。レビューで誤字やリンク切れを防げるため、公開品質が上がります。
デプロイの自動化（CI/CD）
Git への push をトリガーに、自動でビルドや公開を実行できます。GitHub Actions などを使えば、人手ミスを減らし迅速に更新できます。
ファイルベースのメリットと注意点
コンテンツがファイルで管理されると差分が見やすくなります。一方で画像などの大きなバイナリは扱いに注意が必要です。競合が起きた場合は、手動で内容を統合します。ここで適切な運用ルール（誰が何を編集するか）を定めるとスムーズです。
最後に
Git と CMS の連携は、履歴管理、共同作業、公開作業の自動化で運用を安定させます。まずは小さなコンテンツから試して慣れていくと良いでしょう。
Git ベースのヘッドレス CMS（Decap CMS と Contentrain）
概要
GitベースのヘッドレスCMSはコンテンツそのものをGitリポジトリ（Markdown、YAMLなど）で管理し、編集用のUIだけを提供するタイプです。編集操作は最終的にコミットやプルリクエストに変換されるため、履歴管理や差分確認が容易です。
Decap CMS（旧 Netlify CMS）
- 特徴: サイトに管理画面を組み込み、リポジトリに直接コミットします。静的サイトジェネレータ（Hugo、Gatsby、Eleventyなど）と相性が良いです。
- 利点: 自由度が高く、カスタムフィールドやワークフローを細かく設定できます。オープンソースで自己ホスティング可能です。
- 注意点: 初期設定や認証まわりの実装に工数がかかります。運用担当者の要件を先に決めると導入がスムーズです。
Contentrain
- 特徴: SaaS型のダッシュボードを提供し、ログイン→Git連携で編集できます。ノンエンジニアにも使いやすいUIです。
- 利点: ホスティングや管理画面の用意が不要で、導入が速いです。権限管理やレビューの仕組みが整っています。
- 注意点: サービス依存が生じる点と、カスタマイズの自由度はDecapより制限されます。
比較と運用のヒント
- 小規模でスピード重視ならContentrainが向きます。チームで細かく制御したい場合はDecapが適します。
- Markdown運用、プレビュー、CIとの連携を設計すると編集→公開の流れが安定します。
HubSpot CMS と GitHub（Git）連携
概要
HubSpot CMS のテーマやテンプレートを GitHub と連携すると、変更履歴の管理や自動デプロイが可能になります。ローカルで編集してプルリクエスト（PR）でレビューし、CI でチェック済みのコードだけを本番に反映する運用が作れます。
基本の流れ
- HubSpot CLI でテーマやテンプレートをローカルに取得
- GitHub リポジトリへ push して PR を作成
- レビューと CI（テスト／リンティング）を実行
- マージ時に GitHub Actions が HubSpot に自動デプロイ
導入の簡単な手順
- ローカルに HubSpot CLI を導入し、開発用ポータルからファイルをダウンロードします。フォルダ構成をリポジトリに整理してください。
- GitHub にリポジトリを作成し、コードを push します。ブランチ運用（feature → main）を決めます。
- GitHub Secrets に HubSpot の認証情報（API キーや OAuth トークン）を登録します。
- GitHub Actions を作り、マージ時に CLI を使って HubSpot へアップロードするジョブを設定します。
運用時のポイント
- PR ベースでレビューを必須にして誤反映を防ぎます。
- ステージング用ポータルがあれば、まずそこへデプロイして確認すると安全です。
- CI に HTML/テンプレートのリンティングやリンクチェックを入れると品質が上がります。
- 差分が大きい変更は分割して少しずつマージするとリスクを減らせます。
ロールバックとトラブル対応
Git の revert を使えば簡単に前の状態に戻せます。デプロイ失敗時はまず CI ログと HubSpot のエラーメッセージを確認し、ローカルで再現してから修正します。
WordPress と Git 連携による CMS 運用
概要
WordPressでGitを使う主な目的は、テーマやプラグイン、独自コードの変更履歴管理と共同作業、そして誤った変更からの復元です。コアやアップロード済みメディアを丸ごとGit管理するとリポジトリが大きくなり運用が難しくなる点に注意が必要です。
基本方針
- Gitで管理するのはテーマ、カスタムプラグイン、mu-plugins、設定ファイル（wp-config.phpは環境ごとに分ける）を推奨します。
- uploads（メディア）やデータベースはGitに含めず、別の同期手段やバックアップで扱います。
実践手順（簡潔）
- リポジトリを作成し、.gitignoreで/wp-content/uploads/やnode_modulesを除外します。
- 機能ごとにブランチを切り、プルリクエストでレビューします。
- マージ後はCI（例：GitHub Actions）でビルドと簡単なテストを実行し、本番へデプロイします。
データベースとメディアの扱い
データベースはシリアライズ含むため差分管理に不向きです。WP Migrate DBやWP-CLI、専用サービスで同期します。メディアはオブジェクトストレージ（S3等）や専用同期を使うと便利です。
テーマ・プラグイン開発
テーマはプレーンなフォルダ構成で管理し、バージョンタグでリリースを管理します。プラグインは独立リポジトリにしてパッケージ管理（Composerやzip）で配布すると安全です。
注意点
- 本体ファイルをコミットしないことでアップデートの運用が楽になります。
- マージ衝突は小まめなプルと機能単位のブランチで減らせます。
この手順で、共同作業と安全なロールバックがしやすい運用を目指せます。
