T.I.D.

Git や GitHub と戯れる、オレオレ的おとなの遊び場

Git管理下のWordPressプラグインを公式SVNリポジトリに上げる - Git-svnを使う方法／使わない方法

Git をメインのバージョン管理に使うなら、git-svn は使う必要がないと言う記事。

Git や GitHub で管理する WordPress プラグインを公式の SVN リポジトリに送る方法として git-svn を使うワークフローが多く紹介されている。

これらの問題点は以下の通り。

  • SVN リポジトリから git に取り込む（git svn fetch）際、一本の巨大なリポジトリ・ツリーを頭から検索するため、非常に時間がかかる。
  • SVN へのコミットはすべての変更を集約する必要がある。これには git 側でのマージ処理が必要だが、途中の過程をすっ飛ばして前バージョンと最新をマージするため、コンフリクトが発生する可能性が高い。この解消は全くもって無駄な作業である。
  • git-svn の制限により、サブモジュールが扱えない。
  • 開発の歴史をすべて SVN リポジトリへ引き継ぐため、リポジトリが増大する。

蛇足だが、上記最後の記事には 「公式リポジトリを単にリリース用に使うだけなら、せめて git rebase -i か git merge -squash でやってくれ」 という Otto さんの嘆き が書き込まれている（Otto さん は WordPress のプラグイン開発で有名な人）。

一方、Git / GitHub を主とする開発では、

  • 開発の歴史はすべて Git / GitHub で管理する。
  • 公式 SVN リポジトリは、単にリリース・バージョンの保持のために利用する。

SVN クライアントとして動作する git-svn を使うと、git リポジトリと同時に SVN のリポジトリも同時に生成・管理することになるが、上記を前提とすれば、git-svn を使う必要がない。

基本的には、公式サイトの記事 How to Use Subversion に書かれている手作業をスクリプトで自動化するイメージ。

現在見つけたスクリプトは以下の2系統。どちらもリリース・バージョンを GitHub に push する直前からの利用を想定している。バージョン番号に応じたタグ付けなど、ワン・コマンドによる自動化が可能。一時的に SVN リポジトリを作成するが、残す必要がないので、その都度削除するという潔さ。スクリプトの動作も軽い。

sudar / wp-plugin-in-github

歴史を含めて既存の SVN リポジトリから git にクローンを作成する clone-from-svn-to-git.sh と git で管理しているファイル群を SVN に上げる deploy-plugin.sh がメイン。前者は git-svn のインストールが必要だが、最初から GitHub で開発している場合には後者だけを使えば良く、git-svn のインストールは不要。

assets への転送、add-textdomain.php や makepot.php による言語ファイルの更新（Otto さんの記事 Language Packs 101 – Prepwork を参照）も含まれており、至れり尽くせりのスクリプト。

また、マークダウンで書かれた README.md を readme.txt に変換する readme-converter.sh や、プラグインの zip アーカイブを作成する create-archive.sh もあり、すべての作業内容が網羅されている。

詳しくは、以下の紹介記事を参照のこと。

GaryJones / wordpress-plugin-git-flow-svn-deploy

deanc / wordpress-plugin-git-svn から派生したスクリプトで、サブモジュールや assets の転送、途中で削除されたファイルなどの対応もサポート。

私はこのスクリプトを元に自分の構成に合わせて修正、利用した。

いずれにしても盲目的に実行するのではなく、自分の環境に合っているかどうか、スクリプトの各行を吟味して実行するが吉。さもないとトラブルの際、うろたえることになる。

またまた蛇足だが、Create Git Repositories for Plugins and Themes には公式リポジトリの GitHub 化が提案されている。WP.org のアカウントとリポジトリのアカウントを同一にしているのをどうするかが一番の問題点と見た。

Comments