WordPress のテーマを Git で管理するなら、リポジトリに入れるのは基本的に「自分で書いたテーマのフォルダ」だけにし、node_modules やビルド成果物、秘密情報を含む wp-config.php は除外するのが基本です。そのうえで style.css のバージョン番号と Git のタグをそろえておくと、どの版が本番に出ているかを後から追えます。この記事では、リポジトリの範囲の決め方、.gitignore の例、バージョンの付け方、サーバーへの反映方法までを説明します。
どこをリポジトリにするか
最初に決めるのは「どのフォルダを Git の管理対象にするか」です。代表的な選択肢は2つあります。
- テーマフォルダだけをリポジトリにする：
wp-content/themes/my-theme/でgit initします。テーマ単体で開発・配布する場合や、本番サーバーのWordPress本体を触りたくない場合に向いています。 - サイト全体をリポジトリにする：WordPress 本体やプラグインも含めて管理する構成です。本体やプラグインのバージョンもそろえたいチーム開発で使われますが、除外設定が複雑になります。
テーマのバージョン管理が目的なら、テーマフォルダだけを対象にするのが分かりやすく、事故も起きにくい構成です。WordPress 本体や公式ディレクトリのプラグインは、WordPress の更新機能や WP-CLI で管理できるため、テーマと同じリポジトリに入れる必要はあまりありません。
親テーマ（配布テーマ）をカスタマイズしている場合は、親テーマではなく子テーマをリポジトリにします。親テーマは配布元の更新で上書きされるため、自分の変更は子テーマに集めておくほうが管理しやすくなります。
リポジトリを作る
テーマフォルダに移動して初期化します。
cd wp-content/themes/my-theme
git init
git add .
git commit -m "Initial commit"GitHub や GitLab などのリモートリポジトリを使う場合は、テーマのコードが外部に置かれることになります。有料テーマのコードを含む場合はライセンス上の扱いを確認し、リポジトリは非公開にしておきます。
.gitignore で除外するもの
コミットすべきでないものは、大きく分けて「自動生成されるもの」「環境ごとに違うもの」「秘密情報」です。テーマフォルダ直下に置く .gitignore の例を示します。
# 依存パッケージ（package.json / composer.json から復元できる）
node_modules/
vendor/
# ビルド成果物（サーバー側やCIでビルドする運用の場合）
/build/
/dist/
# ログ・OSやエディタの生成ファイル
*.log
.DS_Store
Thumbs.db
.idea/
.vscode/
# 環境ごとの設定・秘密情報
.env判断が分かれるのは vendor/ とビルド成果物（build/ や dist/）です。
- サーバーやCIで
npm run buildやcomposer installを実行できるなら、成果物はコミットせず、.gitignoreに入れます。差分が読みやすくなり、マージ時の衝突も減ります。 - 共用レンタルサーバーなどでビルドできず、
git pullだけで動かしたいなら、成果物もコミットする運用にします。その場合は上の例から/build/やvendor/の行を外します。
どちらにするかはチームで1つに決め、README などに書いておきます。混在すると「ローカルでは動くのに本番ではCSSが古い」といった食い違いが起きます。
すでにコミット済みのファイルは、あとから .gitignore に書いても追跡が外れません。管理から外すには次のようにします（ファイル自体は手元に残ります）。
git rm -r --cached node_modules
git commit -m "Stop tracking node_modules"wp-config.php や秘密情報を入れない
サイト全体をリポジトリにする構成では特に、wp-config.php を誤ってコミットしないよう注意します。DBのパスワードや認証用キーが含まれているため、非公開リポジトリであっても履歴に残すべきではありません。サイト全体を管理する場合のルート側 .gitignore には、少なくとも次のような行を入れます。
wp-config.php
wp-content/uploads/
wp-content/cache/
.envアップロードされたメディア（uploads）も、サイトの運用データなのでコードのリポジトリには含めず、バックアップで別に保管するのが一般的です。万一秘密情報をコミットして共有してしまった場合は、履歴から消すだけでなく、パスワードやキーを変更してください。
style.css のバージョンと Git タグをそろえる
テーマのバージョンは、style.css 冒頭のヘッダーコメントにある Version で管理します。
/*
Theme Name: My Theme
Author: Your Name
Version: 1.2.0
Requires at least: 6.0
Requires PHP: 7.4
Text Domain: my-theme
*/番号の付け方は、互換性を壊す変更・機能追加・修正の順に「1.2.0」のように3つの数字で表すセマンティックバージョニングがよく使われます。リリースするときは、Version を上げてコミットし、同じ番号でタグを付けます。
git add style.css
git commit -m "Bump version to 1.2.0"
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin main --tagsこのバージョン番号は、CSSやJavaScriptを読み込むときのキャッシュ対策にも使えます。
add_action( 'wp_enqueue_scripts', function () {
$version = wp_get_theme()->get( 'Version' );
wp_enqueue_style( 'my-theme-style', get_stylesheet_uri(), array(), $version );
} );wp_get_theme()->get( 'Version' ) は style.css の値を返すので、バージョンを上げるとファイルのURLに付く ?ver= も変わり、ブラウザやCDNに古いファイルが残りにくくなります。
ブランチの使い方
小規模なテーマ開発なら、main を本番に出す版、作業は機能ごとのブランチで行い、確認後に main へマージする程度で十分です。ステージング環境があるなら、ステージングには作業ブランチや develop を、本番には main やタグを反映する、と決めておくと、どの環境に何が出ているかが明確になります。
サーバーへの反映方法
Git で管理したテーマを本番に出す方法は、主に次の3つです。
- サーバー上で git pull する：本番のテーマフォルダをクローンしておき、リリース時に
git pullやタグの checkout をします。手軽ですが、.gitフォルダが公開領域に置かれるため、Webサーバーで.gitへのアクセスを拒否する設定が必須です。 - rsync などで成果物だけを転送する：手元やCIでビルドしたテーマを、
.gitやnode_modulesを除いて転送します。サーバーに Git が無くても使え、不要なファイルを本番に置かずに済みます。 - CI/CD で自動デプロイする：GitHub Actions などで、タグの作成や
mainへのマージをきっかけにビルドと転送を自動で行います。手作業のミスを減らせますが、サーバーの接続情報をCI側のシークレットとして安全に保管する必要があります。
どの方法でも、反映の前にはサイトのバックアップを取り、反映後はトップページと主要ページの表示、管理画面のエラー表示、ブラウザの開発者ツールでCSS・JSが読み込めているかを確認します。
（2026年10月現在）WordPress のテーマヘッダーで使える項目や、各Gitホスティングの機能は今後も変わる可能性があります。style.css のヘッダー項目は WordPress の公式ドキュメントで最新の一覧を確認してください。
まとめ
- リポジトリにするのはテーマフォルダ（カスタマイズなら子テーマ）だけにするのが分かりやすい
node_modulesは除外し、vendorやビルド成果物はサーバーでビルドできるかどうかで扱いを決めるwp-config.php、.env、uploadsはコミットしないstyle.cssのVersionと Git のタグを同じ番号にし、アセットの読み込みにも使う- 反映方法は git pull・rsync・CI/CD から選び、反映前にバックアップ、反映後に表示を確認する