WordPress.org SVN実体験＋コマンドリファレンス

SVNの存在を、審査の途中で初めて知りました
初めての svn commit が、思ったより重く感じました
SVNの用語を、Gitに対応させて覚えると早かった
assets ディレクトリは、リポジトリの直下にあります
使う画像のファイル名は、思ったより厳密です
初回リリースで打ったコマンドの並び
commit前に svn status を見る、というクセ
.git や CLAUDE.md を SVN に上げてしまわないために
Stable tag と tags/ がずれていると、リリースが配信されない
Stable tag に trunk を指定するのは、私はやめました
1.0.6 から 1.0.9.5 まで、週1ペースでリリースしています
GitHubで開発、WordPress.org SVNで配布、という分担
macOSのSVNクライアントは、結局コマンドラインに戻りました
個人開発で branches/ は、ほぼ空のままでいい
commit する前に、私が画面で見ているもの
おまけ：WordPress.org運用で使うSVNコマンドリファレンス
参考にした公式情報
SVNを触り始める前に、誰かに伝えておきたかったこと
関連記事

2026年1月2日の夜、自宅のデスクで、私はSubversionのコマンドを生まれて初めて打ちました。

その日の深夜、WordPress.orgから「Your review has been successfully completed.」というメールが届いて、Rapls PDF Image Creator が承認されたばかりでした。続けて届いたSVNリポジトリのアクセス情報を見ながら、macOSのターミナルを開いて、svn checkout という1行を打つ前に5分ぐらい画面を見つめていました。

普段の開発はずっとGitだけで済ませてきました。GitHubで開発する流れには慣れていても、SVN(Subversion)は名前を聞いたことがあるだけで、自分の手で動かすのは初めてです。WordPress.orgがいまだに集中型のSVNを使っている、という話は耳にしていたものの、自分が触る日が来るとは思っていませんでした。

そもそも、私はSVNの存在を審査の途中まで知りませんでした。プラグインを最初に提出したとき、ZIPの中にバナー画像やアイコンを同梱して出してしまい、レビューチームから「これらはZIPに入れるものではなく、別の場所(SVN)にアップロードしてください」と差し戻されたのが、SVNとの出会いです。

この記事は、Rapls PDF Image Creator を初めてWordPress.orgに公開したときに、SVNまわりで実際にぶつかったことの記録です。コマンドの一覧というより、「何がわからなくて、どう調べて、どう動かしたか」の話に近いです。記事の後半には、SVNコマンドのリファレンスもまとめました。

WordPress.orgのプラグイン審査そのものについては、別記事「WordPressプラグイン審査で差し戻された実体験」にまとめました。本記事はその続編、つまり審査に通ったあとのSVN公開作業に絞った話です。

検証環境(本記事執筆時点)：WordPress 6.9.4 / PHP 8.3.21 / macOS / Xserver スタンダードプラン
SVN初体験：Rapls PDF Image Creator(2026年1月2日夜・自宅にて初回 svn checkout)
承認バージョン：1.0.6 ／本記事執筆時点の最新版：1.0.9.5(週1のペースで9回リリース、合計約7.6MB)

SVNの存在を、審査の途中で初めて知りました

少し時計を巻き戻します。2025年12月16日、Rapls PDF Image Creator の初回提出のときの話です。

当時の私は、プラグイン本体のZIPの中に、WordPress.orgのプラグインページに表示するためのバナー画像やアイコンも一緒に入れて提出していました。assets/banner-772x250.png や assets/icon-128x128.png といったファイルが、プラグイン本体と同じZIPに同梱されている状態です。

この時点では、画像の置き場所として「assetsという名前のフォルダがある」ことしか知りませんでした。GitやGitHubで開発しているとき、JavaScriptやCSSを置く assets/ フォルダはよく見るので、画像も同じ感覚で同梱しただけでした。WordPress.orgが画像をプラグイン本体とは別に管理している、という発想がそもそもありませんでした。

差し戻しメールに、こんな指摘が書かれていました。

We’ve detected WordPress.org directory plugin asset files in your submission. (…) these files (banners, icons, screenshots created for the directory plugin page) are not part of the plugin code and should not be included in your plugin zip file.

「これらの画像はプラグインコードの一部ではありません。ZIPに含めるべきではありません」── 読んだ瞬間、「じゃあ、どこにアップロードすればいいんだろう」と思いました。差し戻しメールの中には、承認後にSVNリポジトリに配置する、という説明も書かれていて、SVNという仕組みがそこに登場します。

このとき初めて、WordPress.orgが配布の仕組みとしてSVNを使っていることを知りました。普段の開発はずっとGitだったので、「いまだにSVN?」と少し驚きました。とはいえ、文句を言っても始まらないので、年末年始は審査対応(exec()削除など)をしながら、SVNの公式ドキュメントをぼちぼち読んでいました。

承認メールが届いて実際に svn checkout を打ったのは、2026年1月2日の夜のことです。

初めての svn commit が、思ったより重く感じました

SVNとGitの一番の違いは、commitの「重み」だと思います。

Gitだと、commitはローカルのリポジトリに記録するだけです。あとからリベースしたり、強制プッシュで歴史を書き換えたり、ある程度やり直しが効きます。私は普段、ちょっとした修正でこまめにcommitして、最後にまとめてpushする、という雑な使い方をしていました。

SVNはこれが通用しません。svn commit を打った瞬間、その変更は中央リポジトリに反映されます。WordPress.orgのSVNの場合、その「中央」がそのまま配布の仕組みにつながっているので、commitは即座にプラグインページの更新に直結します。

このことを、私は1月2日の夜の作業中に身体で覚えました。

SVNリポジトリをcheckoutして、プラグイン本体を trunk/ にコピーして、画像を assets/ に置いて、最初の svn commit を打ちました。コミットメッセージは「Initial release: version 1.0.6」。Enterキーを押した数秒後、ターミナルに「Committed revision」のような行が返ってきました。

「これで作業終わり」と思ってWordPress.orgのプラグインページに行ったら、自分のプラグインのページがすでに「Version 1.0.6」として表示されていました。バナーも、説明文も、ダウンロードボタンも、ぜんぶ動いている。それまでGitHubでprivateリポジトリは触っていたものの、「commitした瞬間に世界に配布される」という感覚は経験がなかったので、少し怖くなりました。

このときから、私はSVNを「気軽に試す場所」ではなく、「リリース済みのものを置く場所」として扱うようになりました。

観点	SVN(集中型)	Git(分散型)
コミットの意味	中央への「公開」	ローカルへの「記録」
オフライン作業	制限あり	自由に可能
履歴の書き換え	基本的に不可	rebase等で可能
ブランチ	ディレクトリのコピー	ポインタの移動
WordPress.orgでの役割	配布の中央サーバー	個人開発の作業場

慣れてしまえば「そういうもの」なのですが、最初の数回のcommitは、Enterキーを押す前に毎回深呼吸していました。

SVNの用語を、Gitに対応させて覚えると早かった

初日の夜、SVNのコマンドを覚えるのに私が一番助かったのは、Gitの用語と並べて整理することでした。

SVN	Gitで言うと	意味
`svn checkout`	`git clone`	作業コピーを作る(初回のみ)
`svn update`	`git pull`	中央の最新状態を取り込む
`svn commit`	`git commit + push`	変更を中央に反映する(2手順が1コマンド)
`svn add`	`git add`	新規ファイルを管理対象にする
`svn status`	`git status`	変更状態を確認する
`svn log`	`git log`	履歴を見る
リビジョン番号(r1, r2…)	コミットハッシュ	連番なのでむしろ直感的
Working Copy	ワーキングツリー	ローカルにcheckoutした作業フォルダ

Gitに慣れている人なら、この対応表だけで初日の作業はだいたい乗り切れると思います。リビジョン番号がコミットハッシュではなく連番(r3441872 のような連続した数字)になっているのは、SVNが集中型で「全体に1本の歴史しかない」からです。並行で枝分かれしないぶん、シンプルに番号が振れる、という発想です。

assets ディレクトリは、リポジトリの直下にあります

差し戻しメールで「画像はSVNにアップしてください」と言われたあと、私は公式ドキュメントを読み返しました。そこで知ったのが、assets/ の置き場所が trunk/ の中ではない、ということです。

SVNリポジトリの構造を見ると、こうなっています。

rapls-pdf-image-creator/
  trunk/
    rapls-pdf-image-creator.php  ← プラグイン本体
    readme.txt
    includes/
    languages/
  tags/
    1.0.6/
  branches/
  assets/                         ← ここにバナー、アイコン、スクリーンショット
    banner-772x250.png
    banner-1544x500.png
    icon-128x128.png
    icon-256x256.png
    screenshot-1.png

rapls-pdf-image-creator/

trunk/

rapls-pdf-image-creator.php ← プラグイン本体

readme.txt

includes/

languages/

tags/

1.0.6/

branches/

assets/ ← ここにバナー、アイコン、スクリーンショット

banner-772x250.png

banner-1544x500.png

icon-128x128.png

icon-256x256.png

screenshot-1.png

差し戻しメールを受け取るまで、私はZIPの中の「assets」フォルダがそのままWordPress.org側で扱われると思い込んでいました。実際は、プラグイン本体(trunk/)とは別の階層に専用のディレクトリが用意されていて、そこに置いた画像だけがプラグインページに反映される仕組みです。

差し戻しメールのおかげで、ZIPに同梱して提出した最初の段階でこのことに気づけたのは、結果的によかったと思います。承認後に自分でSVNを触り始めてから「あれ、画像が表示されない」と詰まっていたら、もっと長く悩んだかもしれません。

▲ リポジトリ直下の assets/ に画像を配置した状態。trunk/assets/ ではない

▲ commit して30分ほど待つと、プラグインページにバナーが反映される

使う画像のファイル名は、思ったより厳密です

WordPress.orgのプラグインバナーは、ファイル名と画像サイズが厳密に決まっています。「だいたいこのサイズ」ではなく、ピクセル単位できっかり合わせる必要があります。

種類	ファイル名	サイズ
バナー(標準)	`banner-772x250.png`	772 × 250 px
バナー(Retina)	`banner-1544x500.png`	1544 × 500 px
アイコン(標準)	`icon-128x128.png`	128 × 128 px
アイコン(Retina)	`icon-256x256.png`	256 × 256 px
スクリーンショット	`screenshot-1.png`、`screenshot-2.png` …	横幅1200px前後を目安

スクリーンショットの番号は、readme.txt の == Screenshots == セクションに書いた説明と対応します。screenshot-1.png はScreenshotsセクションの1番目の説明とペアになる、という関係です。番号と説明がずれると、プラグインページで「説明と画像が噛み合わない」状態になります。

画像を差し替えても、すぐにプラグインページには反映されません。私の感覚では、commit から15分〜数時間ほど待つと変わっています。「反映されない」と思って何度もcommitし直すと、SVNの履歴がぐちゃぐちゃになるので、しばらく待つのがいいです。

初回リリースで打ったコマンドの並び

1月2日の夜、自宅のmacOSで実際に打ったコマンドの順序です。Rapls PDF Image Creator の初回リリースまでの流れになります。

# ① WordPress.org からの承認メールに書かれた SVN URL でチェックアウト
svn checkout https://plugins.svn.wordpress.org/rapls-pdf-image-creator/ wporg-svn
cd wporg-svn

# ② プラグイン本体を trunk/ にコピー(GitHub の public リポジトリからコピー)
cp -r /path/to/rapls-pdf-image-creator-source/* trunk/

# ③ assets/ にバナー、アイコン、スクリーンショットを配置
#    ↑ ここがリポジトリ直下であることに注意。trunk/assets/ ではない
cp /path/to/banner-772x250.png assets/
cp /path/to/banner-1544x500.png assets/
cp /path/to/icon-128x128.png assets/
cp /path/to/icon-256x256.png assets/

# ④ SVN管理対象に追加
svn add trunk/* --force
svn add assets/* --force

# ⑤ commit前に必ず status で確認
svn status

# ⑥ 問題なければ commit
svn commit -m "Initial release: version 1.0.6"

# ⑦ tags/ にリリース版を固定
svn copy trunk tags/1.0.6 -m "Tag version 1.0.6"

# ① WordPress.org からの承認メールに書かれた SVN URL でチェックアウト

svn checkout https://plugins.svn.wordpress.org/rapls-pdf-image-creator/ wporg-svn

cd wporg-svn

# ② プラグイン本体を trunk/ にコピー(GitHub の public リポジトリからコピー)

cp -r /path/to/rapls-pdf-image-creator-source/* trunk/

# ③ assets/ にバナー、アイコン、スクリーンショットを配置

# ↑ ここがリポジトリ直下であることに注意。trunk/assets/ ではない

cp /path/to/banner-772x250.png assets/

cp /path/to/banner-1544x500.png assets/

cp /path/to/icon-128x128.png assets/

cp /path/to/icon-256x256.png assets/

# ④ SVN管理対象に追加

svn add trunk/* --force

svn add assets/* --force

# ⑤ commit前に必ず status で確認

svn status

# ⑥ 問題なければ commit

svn commit -m "Initial release: version 1.0.6"

# ⑦ tags/ にリリース版を固定

svn copy trunk tags/1.0.6 -m "Tag version 1.0.6"

初回 commit のときは、WordPress.orgのユーザー名(私の場合は rapls)とパスワードを聞かれました。macOSのキーチェーンに保存するか聞かれるので、保存しておくと2回目以降は省略されます。

▲ WordPress.orgから届いた承認メール。本文中にSVNリポジトリのURLが記載されている

▲ macOSのターミナルで初回 svn checkout を実行した画面。空のディレクトリ構造がローカルにできる

▲ プラグインページの管理者向けセクションに表示される SVN URL

▲ checkoutした直後のローカルディレクトリ構成。trunk・tags・branches・assets の4つが並ぶ

▲ 初回 svn commit の実行結果。Committed revision 〇〇と返ってきた瞬間、世界に配布される

commit前に svn status を見る、というクセ

初回リリースで一番気を遣ったのは、svn commit を打つ前に svn status を必ず見ることでした。

SVNでは、新しく作ったファイルは svn add で明示的に追加しないと管理対象に入りません。Gitの git add . や git commit -a のようなまとめて追加する感覚でいると、新規ファイルが取り残される可能性があります。逆に、追加したくない開発用ファイル(後述する .git/ や CLAUDE.md など)が紛れ込むリスクもあります。

svn status

1	svn status

表示される記号は何種類かありますが、最初のうちは下の5つだけ頭に入っていれば困りません。

記号	意味	よくある原因
`M`	変更あり	既存のファイルを編集した
`A`	追加予定	`svn add` 済み。次の commit で追加される
`D`	削除予定	`svn delete` 済み
`?`	未管理	新しいファイルを作ったが、まだ `svn add` していない
`C`	競合	変更が衝突している(個人開発ではあまり出ない)

このうち、特に注意すべきは ? です。? が付いているファイルは、ただフォルダに置いただけで、SVNには登録されていません。そのまま commit しても含まれないので、必要なら svn add します。逆に、? が付いているけれど含めたくないファイル(開発用のファイルなど)もあるので、commit前に必ず目で確認します。

▲ svn status の実行結果。? マークの行は新規ファイル。何が含まれて何が含まれないかを毎回チェック

.git や CLAUDE.md を SVN に上げてしまわないために

初回リリース以降、私が一番気をつけているのが、開発用のファイルをSVNに紛れ込ませないことです。

Rapls PDF Image Creator は GitHub の public リポジトリで開発しています。SVNに反映するときは、GitHubのローカルリポジトリから必要なファイルだけをコピーする、という形をとっています。

このとき、SVN trunk/ に絶対に入れたくないものがあります。

.git/ ── Gitのリポジトリ情報。SVNには無関係
.github/ ── GitHub Actions ワークフローなど
CLAUDE.md ── Claude Code 用のプロジェクトメモ。AIエージェントへの指示書なので、ユーザーには配布したくない
.cursorrules や .cursor/ ── Cursor用の設定
node_modules/ ── 依存パッケージ。配布物に含める必要なし
.DS_Store ── macOSが勝手に作るメタデータ
テスト用のオプションを書いたファイル、ローカル実験用のスクリプトなど

これらは「自分が開発するときには必要だが、ユーザーには無関係」というファイル群です。WordPress.orgのSVNはユーザーへ直接配布される場所なので、こういう開発用の中身を入れてはいけません。

私は最初、「GitHubからまるごとコピーすれば早い」と思っていましたが、これだと .git/ や CLAUDE.md がそのままSVNに上がってしまいます。1〜2回はやらかしかけて、svn status で気づいて add する前に止めました。

今は、bashスクリプトでGitHubのローカルリポジトリから必要なファイルだけを選んでSVN trunk/ にコピーする運用にしています。

# Rapls PDF Image Creator のSVNリリース用 bashスクリプト(抜粋)
SOURCE=/path/to/github/rapls-pdf-image-creator
DEST=/path/to/wporg-svn/trunk

# 必要なファイルだけ rsync で同期(除外リスト付き)
rsync -av --delete \
  --exclude='.git' \
  --exclude='.github' \
  --exclude='CLAUDE.md' \
  --exclude='.cursor*' \
  --exclude='node_modules' \
  --exclude='.DS_Store' \
  --exclude='tests' \
  "$SOURCE/" "$DEST/"

# Rapls PDF Image Creator のSVNリリース用 bashスクリプト(抜粋)

SOURCE=/path/to/github/rapls-pdf-image-creator

DEST=/path/to/wporg-svn/trunk

# 必要なファイルだけ rsync で同期(除外リスト付き)

rsync -av --delete \

--exclude='.git' \

--exclude='.github' \

--exclude='CLAUDE.md' \

--exclude='.cursor*' \

--exclude='node_modules' \

--exclude='.DS_Store' \

--exclude='tests' \

"$SOURCE/" "$DEST/"

このスクリプトを使うようになってから、SVNに紛れ込ませる事故はなくなりました。手作業のcpだと「うっかり」がどうしても出るので、スクリプトで決めておいたほうが安全です。

Stable tag と tags/ がずれていると、リリースが配信されない

SVNの操作とは別に、もうひとつ理解しておく必要があるのが Stable tag の仕組みです。

readme.txt の冒頭付近に、こんな行があります。

Stable tag: 1.0.6

1	Stable tag: 1.0.6

WordPress.orgは、この値を見て「どのバージョンをユーザーに配布するか」を決めています。Stable tag: 1.0.6 と書いてあれば、tags/1.0.6/ に置いてあるコードが配布されます。

新しいバージョンを出すときは、3つの値が同じになっているかをcommit前に確認しています。

readme.txt の Stable tag
メインPHPファイルの Version
tags/ の中に作成するディレクトリ名

たとえば v1.0.7 を出すなら、こうなります。

readme.txt:
  Stable tag: 1.0.7

rapls-pdf-image-creator.php:
  Version: 1.0.7

SVN:
  tags/1.0.7/

readme.txt:

Stable tag: 1.0.7

rapls-pdf-image-creator.php:

Version: 1.0.7

SVN:

tags/1.0.7/

3つともきっちり合っていれば、ユーザーには WordPress 管理画面の「更新があります」通知が届き、ダウンロードしたコードも v1.0.7 のもの、という形になります。私はこれまで9回リリースしてきましたが、ありがたいことにバージョン番号のずれによる事故はまだ起きていません(その代わり、リリース直前の確認には毎回それなりに時間をかけています)。

▲ svn copy trunk tags/1.0.7 でリリース版を tags/ にコピーした画面

Stable tag に trunk を指定するのは、私はやめました

WordPress.orgでは、Stable tag に trunk という値を指定することもできます。これを使うと、tags/ を使わずに、trunk/ の最新コードがそのままユーザーに配布される、という運用になります。

初期のころ、これは「ラクそうだな」と思っていました。svn copy を打たなくていいので、リリース作業のステップが1つ減ります。

ただ、実際にやってみると、これは個人開発者の現実に合わない感じがしました。

trunk に「リリースとして出していい状態」だけを置く、と決めれば確かに動きます。しかし先に書いたとおり、開発用のファイル(.git や CLAUDE.md など)がうっかり混ざるリスクが常にあります。trunk が即配布だと、そういう「うっかり」が一発でユーザーに届きます。

個別の tags/1.0.6/ 形式にしておけば、たとえ trunk に何か事故的に入っても、ユーザーが受け取るのは tags/ に置いた固定版だけです。trunk を「次のリリースに向けた作業場」として使えるので、心理的にも余裕が出ます。

WordPress.org の公式ドキュメントでも、tags/ を使う運用が推奨されています。私もこれに従っています。

1.0.6 から 1.0.9.5 まで、週1ペースでリリースしています

2026年1月2日の初回リリース以降、私は約週1回のペースで Rapls PDF Image Creator を更新しています。本記事執筆時点までのリリース履歴はこんな感じです。

バージョン	位置づけ
1.0.6	初回承認・初回SVNリリース(1月2日夜)
1.0.7	readme.txtの誤記修正、URLの差し替えなど
1.0.7.1	軽微な修正
1.0.9	CMYK PDFの真っ黒問題に対応(別記事に詳細)
1.0.9.1	1.0.9のフォローアップ修正
1.0.9.2 〜 1.0.9.5	細かい修正の積み重ね

合計の svn commit 数は十数回、リポジトリの総容量は約7.6MBです。SVNは「気軽に commit する場所ではない」と最初に決めたので、commit 1回がおおむね1リリースに相当しています。GitHubの public リポジトリでは数百 commit を重ねていますが(現行のリポジトリは作り直してから14commit)、SVNは公開版のスナップショットだけが並ぶ静かな状態です。

2回目以降のリリースは、初回の経験のおかげでほぼ機械的な作業になりました。

# ① 作業前に最新化
svn up

# ② bashスクリプトで GitHub から trunk/ に同期
./scripts/sync-to-svn.sh

# ③ readme.txt の Stable tag を更新
# ④ メインPHPファイルの Version を更新

# ⑤ commit前の最終確認
svn status
svn diff

# ⑥ trunk を commit
svn commit -m "Release 1.0.7"

# ⑦ tags にリリース版を作成
svn copy trunk tags/1.0.7 -m "Tag version 1.0.7"

# ① 作業前に最新化

svn up

# ② bashスクリプトで GitHub から trunk/ に同期

./scripts/sync-to-svn.sh

# ③ readme.txt の Stable tag を更新

# ④ メインPHPファイルの Version を更新

# ⑤ commit前の最終確認

svn status

svn diff

# ⑥ trunk を commit

svn commit -m "Release 1.0.7"

# ⑦ tags にリリース版を作成

svn copy trunk tags/1.0.7 -m "Tag version 1.0.7"

慣れると、この一連の作業は10分ぐらいで終わります。ただ、慣れたころほど Stable tag の更新を忘れるのが怖いところです。私は今でも、リリース直前に readme.txt とメインPHPファイルを開いて、Versionの値を声に出して読んで確認するようにしています。

GitHubで開発、WordPress.org SVNで配布、という分担

運用が落ち着いてみると、私のなかで役割分担はこんな形に固まりました。

場所	役割
GitHub(public)	開発、テスト、変更履歴の整理、Issue管理
WordPress.org SVN	配布、公開、リリース版の固定

GitHub側では、ブランチを切って実験的な修正を試したり、コミットメッセージを書き散らしたり、自由にやります。CLAUDE.mdにメモを書き残してClaude Codeと作業を進めることもあります。.cursor/ には Cursor 用の設定、tests/ にはローカルでのテストスクリプト。要するに、自分が開発するために必要なものはすべて GitHub に置いてあります。

そして「これは次のリリースとして出してよい」と判断したものだけ、bashスクリプトでGitHubからWordPress.orgのSVN trunk/ に同期して commit します。GitHub Actionsでの自動デプロイ(10up/action-wordpress-plugin-deploy)も知っていますが、まだ手動で動かしています。週1ペースの個人プラグインなら、手動でも十分まわせるサイズだと感じています。

macOSのSVNクライアントは、結局コマンドラインに戻りました

私はWindowsの世界でTortoiseSVNが定番、ということは知っていました。エクスプローラーの右クリックメニューからSVN操作ができる、視覚的に分かりやすいツールです。

macOSにも似た立ち位置のツールがいくつかあります。私が試したのは SnailSVNLite(バージョン 1.15.13)というFinder統合型のクライアントでした。Finderの右クリックメニューからcheckout、update、commitなどができるようになります。

ただ、私の用途には合いませんでした。Finderのメニューに項目が増えるのは便利なのですが、commit前のファイル確認画面の動作が少し重く、コマンドラインで svn status を打つほうが結局早かったのです。1〜2回試して、メインの作業はターミナルに戻しました。

これは私の好みもあると思います。普段からターミナル中心で作業する人なら、macOSはコマンドラインのSVNクライアントだけで困らないはずです。SnailSVNLite が合うかどうかは、Finder統合に慣れているかどうかで分かれるところだと思います。

Windows環境であれば、TortoiseSVNを使う選択肢もあります。私自身は使っていませんが、Windowsで個人開発をしている方にはよく勧められているツールなので、コマンドラインに馴染めない場合は候補になります。

やりたいこと	コマンド	TortoiseSVNでの対応操作
作業コピーを作る	`svn checkout`	右クリック → SVN Checkout
最新化する	`svn update`	右クリック → SVN Update
変更状態を見る	`svn status`	右クリック → Check for Modifications
commitする	`svn commit`	右クリック → SVN Commit
tagを作る	`svn copy`	右クリック → TortoiseSVN → Branch/Tag
変更を取り消す	`svn revert`	右クリック → TortoiseSVN → Revert

▲ TortoiseSVNの右クリックメニュー(Windowsエクスプローラー上)

結局、ツールが何であれ、SVNでやることは大きくは変わりません。大事なのは、commit前に何を確認するか、というほうだと思います。

個人開発で branches/ は、ほぼ空のままでいい

SVNには branches/ というディレクトリもありますが、個人でWordPress.orgプラグインを開発している間は、ここは空のままで問題ありません。

branches は、複数人で同時に異なる機能を開発するときの分岐用ディレクトリです。「機能Aを誰かが開発中、機能Bを別の誰かが開発中、最終的にtrunkにマージする」というワークフローのために用意されています。

個人開発で、しかもGitHubで開発を済ませている場合、SVNのbranches/を使う場面はまずありません。私のRapls PDF Image CreatorのSVNリポジトリも、branches/ はずっと空のままです。

気にせず、trunk/、tags/、assets/ の3つだけを正しく扱うことに集中したほうがいいです。

もしチーム開発でSVNを直接使う場合は、feature(機能開発用)・release(リリース準備用)・hotfix(緊急修正用)のブランチを切る運用が一般的です。svn copy ^/trunk ^/branches/feature-123 のようにディレクトリのコピーとしてブランチを作り、作業後は svn merge で trunk に取り込みます。^/ はリポジトリルートのショートカットです。とはいえ、これらは個人プラグイン開発の話の範囲ではないので、深入りはしません。

commit する前に、私が画面で見ているもの

初回リリースから数か月、9回のリリースを重ねたあとも、commit前に毎回確認している項目があります。覚書のような感覚で書いておきます。

まず svn up で最新状態にします。別のPCで作業した形跡がないかの確認です。続けて svn status を見て、? マーク(未管理ファイル)が残っていないかチェックします。残っていたら、必要なものは svn add、不要なもの(.gitやCLAUDE.mdなど)はそのまま放置するか、誤って trunk/ に入っていれば削除します。

そのあと svn diff で変更内容を見ます。意図しない修正(エディタが勝手に整形した、改行コードがCRLFになった、など)が混ざっていないかの確認です。

続けて、配布用ファイルとして問題ないかをチェックします。.git や node_modules、CLAUDE.md といった開発用のディレクトリやファイルが trunk/ に紛れ込んでいないか。WordPress.orgのSVNはユーザーに配布される場所なので、開発用の中身を入れてはいけません。

最後に readme.txt の Stable tag、メインPHPファイルの Version、これから作る tags/X.X.X/ のバージョン名が、3つすべて同じ値になっているかを確認します。ここがずれているとリリースが正しく配信されません。

これらをひととおりチェックしてから svn ci -m "Release X.X.X" を打って、続けて svn copy trunk tags/X.X.X -m "Tag version X.X.X"。

慣れると10分ぐらいの作業ですが、最初の数回は1時間ぐらいかけてもいいと思います。SVNのcommitは即配布なので、ゆっくり確認するに越したことはありません。

おまけ：WordPress.org運用で使うSVNコマンドリファレンス

ここからはおまけです。Rapls PDF Image Creator の運用で実際に使ったSVNコマンドを、用途別にまとめました。困ったときにここだけ見れば作業が進む、という形を目指しています。

初回セットアップ系

コマンド	説明
`svn checkout <URL> <dir>`	リポジトリの作業コピーを取得する。略称 `svn co`
`svn checkout --depth empty <URL>`	空のチェックアウト。必要なディレクトリだけ後から取得
`svn info`	現在の作業コピーのリポジトリURLやリビジョン番号を確認
`svn --version`	SVNクライアントのバージョン確認

日常作業系

コマンド	説明
`svn update` / `svn up`	中央リポジトリの最新状態を取り込む
`svn status` / `svn st`	変更状態を確認(commit前に必ず実行)
`svn status -u`	サーバー側の更新状況も含めて表示
`svn diff`	変更内容を確認
`svn diff > changes.patch`	差分をファイルに保存(レビューや退避に便利)
`svn diff -r 100:HEAD`	リビジョン100から最新までの差分を表示
`svn log`	commit履歴を表示
`svn log -l 10`	直近10件のcommit履歴のみ表示
`svn log -v`	変更ファイルの一覧つきで履歴を表示

ファイル管理系

コマンド	説明
`svn add <path>`	新しいファイル/ディレクトリを管理対象に追加
`svn add * --force`	カレント直下の未管理ファイルをまとめて追加
`svn delete <path>` / `svn rm`	ファイルを削除予定にする(次のcommitで反映)
`svn move <src> <dst>`	ファイルを移動・リネーム(履歴を保つ)
`svn copy <src> <dst>`	ファイルやディレクトリをコピー(tag作成にも使う)
`svn revert <path>`	未commit の変更を取り消す(注意:取り消しは効かない)
`svn revert -R .`	カレント以下の変更をすべて取り消す

commit系

コマンド	説明
`svn commit -m "msg"`	変更を中央リポジトリへ反映。略称 `svn ci`
`svn commit -F message.txt`	メッセージをファイルから読み込んで commit(長文向け)
`svn commit --depth empty .`	このディレクトリ自体のプロパティ変更だけを commit
`svn commit trunk/file.php -m "..."`	特定のパスだけを commit

リリース・tag系(WordPress.orgで重要)

コマンド	説明
`svn copy trunk tags/1.0.7 -m "Tag 1.0.7"`	trunk の現在の状態を tags/1.0.7 に固定(リリース)
`svn copy ^/trunk ^/tags/1.0.7 -m "..."`	サーバー側で直接コピー(ローカル更新不要)
`svn list ^/tags`	tags/ にあるリリース一覧を確認
`svn delete ^/tags/1.0.6.1 -m "Remove broken tag"`	誤って作ったtagを削除(慎重に)

困ったとき系

コマンド	説明
`svn cleanup`	作業コピーがロックされた・操作が中断したときの修復
`svn cleanup --remove-unversioned`	SVN管理外のファイルをまとめて削除(危険なので確認後)
`svn resolve --accept mine-full <path>`	競合を「自分側を採用」で解決
`svn resolve --accept theirs-full <path>`	競合を「中央側を採用」で解決
`svn upgrade`	古い形式の作業コピーを最新形式に変換
`svn auth --remove <realm>`	保存された認証情報を削除(パスワード変更時など)

WordPress.org特有の小技

頻繁に使うわけではありませんが、覚えておくと作業が早くなる小技です。

# 削除されたファイルを一括で svn delete に登録
svn status | grep '^!' | awk '{print $2}' | xargs svn delete

# 未管理ファイルを一括で svn add に登録(中身はよく確認してから!)
svn status | grep '^?' | awk '{print $2}' | xargs svn add

# 特定リビジョンの状態をエクスポート(配布物の検証用)
svn export -r 100 ^/tags/1.0.6 /tmp/check-1.0.6/

# 任意の2リビジョン間の差分をパッチ形式で出力
svn diff -r 100:200 > release-1.0.7-changes.patch

# tags/ 配下を含めずに trunk と assets だけ checkout
svn checkout --depth empty https://plugins.svn.wordpress.org/your-plugin/ work
cd work
svn update --set-depth infinity trunk
svn update --set-depth infinity assets

# 削除されたファイルを一括で svn delete に登録

svn status | grep '^!' | awk '{print $2}' | xargs svn delete

# 未管理ファイルを一括で svn add に登録(中身はよく確認してから!)

svn status | grep '^?' | awk '{print $2}' | xargs svn add

# 特定リビジョンの状態をエクスポート(配布物の検証用)

svn export -r 100 ^/tags/1.0.6 /tmp/check-1.0.6/

# 任意の2リビジョン間の差分をパッチ形式で出力

svn diff -r 100:200 > release-1.0.7-changes.patch

# tags/ 配下を含めずに trunk と assets だけ checkout

svn checkout --depth empty https://plugins.svn.wordpress.org/your-plugin/ work

cd work

svn update --set-depth infinity trunk

svn update --set-depth infinity assets

最後の「tagsを含めない部分checkout」は、リポジトリが大きくなってきたときに地味に効きます。tags/ には過去のすべてのリリースが詰まっているので、ある程度バージョンを重ねると通常のcheckoutが重くなります。trunk と assets だけあれば日常作業はできるので、ここを --depth empty + --set-depth infinity で絞り込む運用です。

参考にした公式情報

SVNまわりで迷ったときに、私が実際に見ていた公式ドキュメントを置いておきます。日本語の解説記事よりも、ここに書いてある情報のほうが正確で、最新です。

確認日：2026年5月5日

SVNを触り始める前に、誰かに伝えておきたかったこと

2026年1月2日の夜、自宅のmacOSでSVNを初めて触ってから、ここまで来るのに私はそれなりに学びがありました。差し戻しメールでSVNの存在を知ったところから、commit前に svn status を見るクセを身につけるところまで、どれも公式ドキュメントには書いてあったのに、最初は読み流していたから引っかかった、という類のものです。

振り返ってみると、SVNは怖いものではありません。ただ、Gitと同じ感覚で触ると、commitの重みやファイル管理の感覚にずれがあって、何度か焦ることになります。

WordPress.orgのSVNを「開発の場所」ではなく「配布する棚」として捉えると、扱いがぐっと楽になります。trunk/ には次のリリースに出してよい状態のものだけ、tags/ にはリリース済みの固定版、assets/ には(リポジトリ直下に!)バナーやアイコン。.git や CLAUDE.md などの開発用ファイルは bashスクリプトの除外リストで弾く。commit前に svn status と svn diff を見るクセをつければ、初回公開で大事故になることはまずありません。

初めてのプラグイン公開では、審査対応そのものでも疲れます。そのうえでSVNでつまずくと、本当にしんどいです。私の経験が、これからWordPress.orgにプラグインを公開する誰かの時間を、少しでも節約できればうれしいです。

WordPress.org に初めて出した自作プラグインが2回差し戻された話｜実体験で書く WordPress プラグイン審査の全記録 ── プラグイン公開時に踏んだレビューの落とし穴。SVN 作業の前段に当たる話。
Rapls PDF Image Creator｜WordPress PDFサムネイル生成プラグイン ── 実際に SVN で公開したプラグインの一例。

WordPress.orgプラグイン公開のSVN作業を1から学んだ記録｜体験談＋コマンドリファレンス