Contents
WordPress 開発における最初の貢献は、2020年5月でした。それは Gutenberg プロジェクトであり、それ以降継続的に貢献を続けてきました。Gutenberg プロジェクトのソースコードは GitHub でホストされているため、そこで git コマンドの使い方、ブランチの管理、プルリクエストの提出方法など、様々なことを学んできました。
一方、 WordPress コアは Git ではなく SVN でソースコードが管理されています。私は、2024年7月にコアコミッターとしてノミネートされ、そのコードベースへのコミット権限があったにもかかわらず、まだ一度も自分自身でコミットを実行したことがありませんでした。
この記事では、自分がどのようにして WordPress の開発を行っているか、またどのようにして WordPress コアに最初のコミットを行ったかを紹介したいと思います。また、私は Windows OS マシンを使用していることに注意してください。
どのように開発しているか
コードエディターと WSL
コードエディターは Cursor を使用しています。そこに WSL プラグインをインストールし、様々なプロジェクトに接続しています。

つまり、ホスト OS 上ではなく、WSL2 (Ubuntu) の中でほぼ全ての開発を行っています。これまでの経験上、ホスト OS 上よりもパフォーマンスが良く、npm ライブラリのインストールやプロジェクトのビルドが高速に行えるからです。さらに、WSL2 の中では本物の Linux が動いており、万が一問題が発生した場合でも、ホスト OS に影響を与えることなく環境を再構築できます。
その WSL の中に、自身の GitHub アカウントにフォークした wordpress-develop リポジトリをクローンしています。
Node バージョン管理ツール
Node.js のバージョン管理ツールとして、Volta を使用しています。基本的には Node バージョン22を使用していますが、プロジェクトによっては、Node バージョンが 高すぎるとスクリプトが動作しない場合があるため、以下のようなコマンドで Node のバージョンを変更しています。
volta install node@20
このコマンドは、その Node バージョンに付属する npm も自動的にインストールしてくれるため、非常に便利です。
Git コマンド、GitHub コマンド
非常に基本的なコマンドしか使用していませんが、作業をスムーズに行うために、以下のエイリアスを登録しています。
s = status # Show working directory status
co = checkout # Switch branches or restore files
b = branch # List, create, or delete branches
lo = log --oneline # Show commit history in one line per commit
さらに、プルリクエストをローカルでチェックアウトしてレビュー・テストするために、以下の GitHub CLI コマンドを頻繁に使用しています。
gh pr checkout {pr_number}
コミットするための準備
これまで何度もパッチやプルリクエストを提出してきましたが、それらはすべて、別のコミッターによってコミットしていもらっていました。自身でコミットするためには、まず最初に SVN リポジトリの作業コピーをローカルに作成する必要あります。
Slack チャンネルでコアコミッター達にアドバイスを求めたところ、Windows を使用しているコミッターの多くは、SVN コピーを WSL2ではなくホスト OS に作成していることを教えてもらいました。
おそらく、WSL に Subversion CLI をインストールすることで、WSL からでもコアにコミットできるかもしれません。しかし、github ミラーである wordpress-develop と混同されることを避けるため、私もホスト OS でコミットの環境を構築することにしました。
SVN クライアントのインストール
Git の場合は GUI よりも CLI を好みますが、SVN にはまだ不慣れなので、Windows 用 Subversion クライアントである TortoiseSVN を導入しました。過去に、自身のプラグインを初めて .org に公開したときにこのツールを使用したはずですが、それ以降ほとんど使用していなかったため、おそらくアンインストールしてしまったんだと思います。
インストール時の注意点としては、将来的に SVN コマンドラインを使用する可能性があるため、”Command line client tools” オプションを有効化したことです。

その後、このドキュメントに従って、WordPress Trunk をチェックアウトします。将来的に別のブランチのコピーも作成する可能性も考慮し、wordpress-svn/trunk ディレクトリを使用しました。
チェックアウトした SVN コピーをコードエディターで開きます。svn info を実行して、CLI が正しく動作していることを確認します。
$svn info
Path: .
Working Copy Root Path: D:\Desktop\wp_dev\wordpress-svn\trunk
URL: https://develop.svn.wordpress.org/trunk
Relative URL: ^/trunk
Repository Root: https://develop.svn.wordpress.org
Repository UUID: 602fd350-edb4-49c9-b593-d223f7449a82
Revision: 61089
Node Kind: directory
Schedule: normal
Last Changed Author: wildworks
Last Changed Rev: 61089
Last Changed Date: 2025-10-30 20:54:22 +0900 (Thu, 30 Oct 2025)
また、次のセクションで Grunt タスクを使用するため、ここで npm install も実行しておきます。
さらに、以下のコマンドを実行しておきます。
svn up: リポジトリの最新状態をローカル作業コピーに反映するsvn revert -R .: 作業コピーの変更をすべて破棄する
コミットを実行する
これでコミットの準備ができましたが、私の初めてコミットは、このチケットに関するものでした。
#64153 (REST API: 403 error occur when resolving or reopening note) – WordPress Trac
パッチを適用する
このチケットに対して GitHub プルリクエストが提出され、承認されています。GitHub プルリクエストはコードレビューのためのものであるため、このプルリクエストをマージすることはできません。このプルリクエストを、ローカルの SVN リポジトリに適用するための便利な Grunt タスクがあるため、それを使用してパッチを適用します。
$ npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/10430
> [email protected] grunt
> grunt patch:https://github.com/WordPress/wordpress-develop/pull/10430
package.json has not been modified.
Running "patch:https://github.com/WordPress/wordpress-develop/pull/10430" (patch) task
Fatal error: spawn patch ENOENT
Fatal error: spawn patch ENOENT というエラーが発生し、パッチが適用できませんでした。このエラーについて調べたところ、patch コマンドがみつからないことが原因であるようです。
幸い、自分のマシンには Git for Windows がインストールされており、その中に patch.exe コマンドがあるようです。CMD または PowerShell から Git Bash に切り替え、もう一度パッチの適用を試みてみます。
$ npm run grunt patch:https://github.com/WordPress/wordpress-develop/pull/10430
> [email protected] grunt
> grunt patch:https://github.com/WordPress/wordpress-develop/pull/10430
package.json has not been modified.
Running "patch:https://github.com/WordPress/wordpress-develop/pull/10430" (patch) task
patching file src/wp-includes/script-loader.php
Done.
パッチが適用された後に、svn diff コマンドで変更を念のためもう一度確認しておきます。
コミットメッセージを作成する
WordPress では、コミットメッセージに関して厳格なフォーマットやルールが定義されています。このドキュメントを参照し、コミットメッセージを作成します。
Editor: Add `auth_callback` to `_wp_note_status` comment meta.
Adds an `auth_callback` to the `_wp_note_status` comment meta so that only users with the `edit_comment` capability can update this meta field via the REST API.
This is necessary to ensure that users can properly resolve or reopen Notes.
Props wildworks, adamsilverstein, westonruter, mamaduka, desrosj.
Fixes #64153.
TortoiseSVN を使用してコミットする
将来的には CLI でコミットを実行するかもしれませんが、SVN に慣れるまでは、TortoiseSVN を使用することにします。ファイルエクスプローラーを開き、wordpress-svn/trunk ディレクトリを右クリックし、TortoiseSVN > Commit メニューにアクセスします。

先ほど作成しておいたコミットメッセージをペーストします。さらにもう一度、コミットによって変更されるファイルが正しいかどうかを確認します。

「OK」ボタンを押すと、認証ダイアログが表示されました。WordPress SVN には、許可された WordPress.org ユーザーしかコミットできないからです。

自分のユーザー名とパスワードを入力し、「OK」ボタンを押します。コミット処理が実行され、正しくコミットされました!

最後に、このコミットが Trac (WordPress のバグトラッカー、プロジェクト管理ツール) にも反映されていることを確認します。
Changeset 61089 – WordPress Trac
参考資料
- コアコミッターのワークフロー – Japanese Team – WordPress.org 日本語
- コミッターになったら – Japanese Team – WordPress.org 日本語
- SVN によるインストール – Japanese Team – WordPress.org 日本語
- コードレビューのための GitHub プルリクエスト – Japanese Team – WordPress.org 日本語
- コミットメッセージ – Japanese Team – WordPress.org 日本語
私の最初のコミットに関してアドバイスをくれ、助けててくれた仲間達に感謝します。

コメントを残す