wiki:pne-book-9-2
 ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Version 10 (modified by imoto, 15 years ago) (diff)

--

TOC

ブランチとマージ

解説：海老原

文：井本

概要

OpenPNE開発では、SVNを用いてソースコードの管理やバグの修正の管理などを行っています。なかでも、これから紹介するブランチとマージはOpenPNE開発において非常に効率よく開発を進める手段として使っています。

そこで、今回は、OpenPNE開発で実際に使われているSVNの使い方をOpenPNEのTracを一部参照しながらブランチとマージを紹介していきます。 

OpenPNE開発情報
http://trac.openpne.jp/

OpenPNEのTrac

それではまず、OpenPNEのTracを見てみましょう。
OpenPNEのTrac(http://trac.openpne.jp)にアクセスすると、TracのTOP画面に来ます。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/1-trac-top.jpg

root

次に、上のグローバルメニューから「Browse Source」をクリックすると、Tracで管理されているOpenPNEのソースを見ることが出来ます。(http://trac.openpne.jp/browser) ここはrootディレクトリで一番上にのディレクトリです。 このrootディレクトリは、大きく分けて二種類のディレクトリ構成になっています。一つ目がOpenPNE本線開発のディレクトリ(/OpenPNE)で、もう一つはOpenPNE本線開発とはことなるプロジェクトです。(NEKOGET_PNESKIN、PNEMonster) 

root

NEKOGET_PNESKIN
OpenPNE
OpenPNE_specification
PNEMonster
prj
sandbox
smtp2pne
work

root/OpenPNE

それでは、OpenPNE本線開発のディレクトリを見ていきましょう。
OpenPNE以下のディレクトリにはbranches、tags、trunkと3つのディレクトリがあります。まず、一番下にあるtrunkはOpenPNE本線開発のメインディレクトリです。基本的に開発版のリリースはこのtrunkでされます。

次に、一番上にあるbranchesですが、直訳すると「枝」です。このbranchesは安定したバージョンの開発や、各個人がもっている機能追加やプロジェクトなどに使われている作業用ディレクトリです。
最後に、tagsはOpenPNEの開発でバージョンを固定した場合にこのディレクトリにソースコードを残しておくためのディレクトリです。 

root/OpenPNE

branches
tags
trunk

root/OpenPNE/branches

まず、一番上にある、branchesから見ていきましょう。
branchesディレクトリは安定したバージョンの開発や、各個人がもっている機能追加やプロジェクトなどに使われている作業用ディレクトリです。
主に三種類のディレクトリがあります。

prj：プロジェクトとしてチームで開発するためのディレクトリ
stable-x.x.x：安定版のバグ修正などを行うディレクトリ
work：個人で行う小さな機能開発を行うディレクトリ

prjディレクトリとworkディレクトリは基本的には新しい機能の開発に使われるディレクトリです。
具体的にどのようにprjディレクトリとworkディレクトリが使われているか実際のOpenPNE開発事例を参照しながら説明していきます。
stable-x.x.xは安定版の機能修正やバグ修正などを行うためのディレクトリです。
例えば、stable-2.10.0で何かバグが発見されたとします。するとまず、stable-2.10.xディレクトリで発見されたバグなどを修正します。そして、一通り修正が終わったら、tagsディレクトリ(root/OpenPNE/tags)にソースを移して、stable-2.10.1として正式にリリースされます。
この様に、stable-x.x.xディレクトリでは、安定版のバグ修正などを行う一時的なディレクトリとなります。

それでは、具体的にどのようにprjディレクトリとworkディレクトリがどの様に使われているか実際のOpenPNE開発事例を参照しながら説明していきます。 

root/OpenPNE/branches

prj
stable-2.6.x
stable-2.8.x
stable-2.10.x
work

root/OpenPNE/branches/prj

まず、prjディレクトリから見ていきます。
現在prjディレクトリには以下のような主要プロジェクトがあります。

このprjディレクトリはプロジェクトごとの機能開発に使用されているディレクトリです。ですので、そのプロジェクトに所属しているメンバーであれば基本的に誰でもソースコードを修正することが許されています。

現在OpenPNEではOpenIDを外部認証として使うことが出来ます。そのときに開発用ディレクトリとして使用されていたディレクトリがこのprjディレクトリにあるopenidディレクトリです。
このopenidのディレクトリのリビジョンを見てもらうと分かると思いますが、ogawa、maruyama、ebiharaなど複数の人でチームを組んでOpenIDの機能開発を行っていたことが分かります。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/2-openid.jpg

この様に、prjディレクトリは複数人で行う大きな機能追加や機能修正をプロジェクトとしてこのディレクトリで管理しています。 

root/OpenPNE/branches/prj

openid
opensocial
pne-api
slavepne2
xhtmlcss
・
・
・

root/OpenPNE/branches/work

次に、workディレクトリを見ていきましょう。 まず、このディレクトリを見て分かるのは個人名が多いということです。基本的にこのworkディレクトリは個人で行う小さな機能開発を行うディレクトリです。 ですので個人が比較的自由にこのディレクトリを使うことが出来るので、小さな機能開発以外にも、OpenPNEで追加してみたい実験的な機能開発や、プロジェクトの機能開発だがprjにソースをマージ(あとで説明)させるほど完成度が高くないソースをここで改良するなどの使い方があります。 prjディレクトリにあったxhtmlcssディレクトリはこのworkディレクトリである程度開発したあとで、prjディレクトリに移動したという経緯があります。 また、workディレクトリは基本的には各個人のディレクトリですので、他の人がソースを書き換えるということはありません。 

root/OpenPNE/branches/work

ebihara
imoto
ishida
kimura
kiwa
ogawa
・
・
・

例として、work以下のebiharaディレクトリを見てみます。
主にebiharaディレクトリでは、プロジェクトに移す前段階でのソースコードを管理しています。ディレクトリのprj_というのは「プロジェクトに移行させるためのディレクトリですよ」ということを表しています。
現在はすべてprj_がついたディレクトリ名ですが、個人的にOpenPNEに取り込んで欲しい機能などがあれば分かりやすい機能名のディレクトリを作って開発することもあります。
prj_dashboadというディレクトリは主にダッシュボード改善プロジェクトの個人開発用として作ったディレクトリです。ダッシュボード改善プロジェクトというプロジェクトが立ち上がった段階でまず、このebiharaディレクトリにprj_dashboadというディレクトリを作ります。ここである程度ソースコードが完成した段階で、prjにソースコードを移してプロジェクトを進めています。

リビジョンを見てもらうと分かると思いますが、ここはebiharaディレクトリで、ebiharaが管理しているので、修正は基本的にebiharaしか行っていません。

root/OpenPNE/branches/work/ebihara

prj_auth_container_mybox
prj_dashboad
prj_debug_2_6_7
prj_dev26_bizfix
prj_dev28_bizfix
・
・
・

この様に、prjとworkにはプロジェクトで開発するか個人で開発するかかという大きな特徴があります。 この特徴に注目しながらtrac.openpne.jpを見ていただけると、「お！この機能はプロジェクトとして動いてるんだ」「この機能はogawaさんが個人で開発しているけど本線に取り込まれるのかな」などまたOpenPNEの最新の動向と今後の方向性も見えてくるかも知れません。

ブランチ

それでは、OpenPNE開発ではどのようにしてブランチを作っているか、どのような方法でブランチを作っているかを実際にブランチを作りながら紹介します。 現在、OpenPNE開発者は主に二種類の方法でブランチを作っています。二種類の方法とは「TortoiseSVNでブランチを作る方法」と「SVNコマンドでブランチを作る方法」です。 OpenPNE開発者には、Eclipseなどの開発環境を使っている人もいますし、vimなどを使ってコマンドラインで開発している人もいます。ですので、それぞれに適したブランチの作り方があります。 そこでこの章ではWindowsクライアントであるTortoiseSVNでブランチを作る方法とsvnコマンドでブランチを作る方法の二種類の方法を紹介するので、ぜひ環境に合わせて使いやすい方法でブランチを作ってみてください。

今回、Subversionの詳しいインストールは割愛しますが、 Debian系であればapt-get、CentOS系であれば、yumで取得できると思います。 

Debian系
apt-get install subversion

CentOS系
yum install subversion

詳しくは、マニュアルを参照してください。 

Debian　ユーザ文書
http://www.debian.org/doc/index.ja.html

CentOS Documentation
http://www.centos.org/docs/

TortoiseSVNでブランチを作る方法

「TortoiseSVNでブランチを作る方法」では、TortoiseSVNというSubversionのWindowsクライアントソフトを使用します。ですので、ここではTortoiseSVNがインストールされていることを前提条件としています。まだインストールをされていない人はTortoiseSVNの日本語翻訳マニュアルがあるのでそちらを参考にしてインストールしてください。 

TortoiseSVN　Subversion クライアント for Windows
http://tortoisesvn.net/docs/nightly/TortoiseSVN_ja/index.html

ブランチの作成

それでは早速ブランチの作成に入ります。 今回はroot/OpenPNE/branches/work/ebihara以下に個人用ブランチを実際に作りながら、説明していきます。 

root/OpenPNE/branches/work/ebihara

prj_auth_container_mybox
prj_dashboad
prj_debug_2_6_7
prj_dev26_bizfix
prj_dev28_bizfix
・
・
・

例として、ここにOpenPNEグローバル変数改善プロジェクトを作っていくことにします。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/3-drectory.png

まず、ローカル環境でOpenPNEのソースをコピーしてきたいディレクトリに移動します。
次に、そのディレクトリで右クリックして、メニューの中から「Repo-browser」をクリックします。
※ディレクトリを移動しなくても右クリックでメニューが出ますが後にその場所にチェックアウト(ソースのダウンロード)することになるので移動しておいたほうがいいと思います。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/4-repo.png

クリック後に、URLというウィンドウが出てくるので、そのURL欄にSVNのURLを入力します。 

https://trac.openpne.jp/svn/

入力後に「Repository Browser」という新しいウィンドウが開きSVNを見ることが出来る様になります。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/5-repo2.png

次に、OpenPNEの最新安定版からブランチを作ります。

現在OpenPNEプロジェクトでは、タグ(OpenPNE/tags)からブランチを作ることを推奨しているので今回はOpenPNE/tags/stable/OpenPNE-2.10.3からブランチを作ることにします。OpenPNE-2.10.3上で、右クリックをすると、下記の画像のようなメニューが表示されるので、今回は「Copy to...」を選択します。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/6-copy_to.png

この「Copy to...」を選択したら、「New name:」という入力フォームが出るのでコピー先を指定します。

今回は、workディレクトリ以下のebiharaディレクトリに作業用ディレクトリ(prj_remove_globals)を作るので下記のURLを指定して「OK」ボタンを押します。

Logが出るのでprj_remove_globalsを追加したメッセージを残します。

このログを残したら、prj_remove_globalsディレクトリが作成され、OpenPNE-2.10.3のソースコードがコピーされています。

指定したバージョンがコピーされているか不安な場合はwebapp/version.phpを開いてOPENPNE_VERSIONを確認してみるといいと思います。

https://trac.openpne.jp/svn/OpenPNE/branches/work/ebihara/prj_remove_globals/

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/7-input_url.png

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/8-url.png 

<?php define('OPENPNE_VERSION', '2.10.3'); ?>

チェックアウト

これで、SVN上ではブランチを作ることが出来ました。

後は、このSVN上にあるソースコードを先ほどのローカルディレクトリに移動してチェックアウトします。

チェックアウトとは、 Subversionリポジトリ上で管理されたファイルをローカルファイルに取得する作業のことです。

それではチェックアウトしていきます。

まず、チェックアウトしたいローカルディレクトリに移動して、右クリックでメニューを表示し、「SVN Checkout...」をクリックします。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/9-checkout_migi.png

クリックすると、Caeckoutという新しいウィンドウが表示されます。

「Repository」の中に「URL of repository」「Checkout directory」とあるので項目を入力します。 

URL of repository
リポジトリのURL
例)https://trac.openpne.jp/svn/OpenPNE/branches/work/ebihara/prj_remove_globals/
Checkout directory
チェックアウトしたいローカルディレクトリ
例)\\colinux\co3k\Programming\sns\prj_remove_globals

OKを押すと、チェックアウトが始まります。

チェックアウトが終了すると、ローカルのprj_remove_globalsディレクトリにソースがコピーされています。 あとは、このソースコードを修正などしたりし、コミットすれば、branches/work/ebihara/prj_remove_globals/のソースコードが修正されています。

コミットとは作業した結果をリポジトリに登録することです。
フォルダ上で右クリックから「SVN Commit...」メニューを選択し、OKを押せば簡単に作業した結果をリポジトリに反映することが出来ます。

コメント

この様に、TortoiseSVNを使用することで、GUIで簡単にブランチの作成、チェックアウト、コミットを行うことが出来ます。

今回の事例ではcolinuxを使用していますが、XAMPPなどを用いてWindowsで開発している人でもTortoiseSVNを使用することが出来るの非常に導入しやすく、使いやすいツールだと思います。

SVNコマンドでブランチを作る方法

次に、SVNコマンドでブランチを作る方法を紹介していきます。

ブランチの作成

まずは、作業ディレクトリに移動してください。 

co3k@colinux:~/Programming/sns$

次に、SVNのsvn copyコマンドを使ってコピーします。

svn copyコマンドは半角スペースの後にSVNのコピー元URL、また半角スペースの後に続けてSVNのコピー先URLを指定します。これで、リポジトリのコピーが完了しました。

svn copy SVNのコピー元URL SVNのコピー先URL

例)
co3k@colinux:~/Programming/sns$ svn copy https://trac.openpne.jp/svn/OpenPNE/tags/stable/OpenPNE-2.10.3/ https://trac.openpne.jp/svn/OpenPNE/branches/work/ebihara/prj_remove_globals/

チェックアウト

次に、リポジトリのソースをローカルにチェックアウトします。 先ほどはcopyコマンドを使いましたが、チェックアウトはcheckoutコマンドを使用します。チェックアウトしたいディレクトリに移動して、チェックアウトコマンドを実行するだけでそのディレクトリにチェックアウトすることが出来ます。 

svn checkout SVNのリポジトリURL

例)
co3k@colinux:~/Programming/sns/ $ svn co https://trac.openpne.jp/svn/OpenPNE/branches/work/ebihara/prj_remove_globals/ prj_remove_globals

コマンドの説明

SVNにはsvnコマンドと呼ばれるさまざまコマンドがあります。 詳しくはSVNのヘルプを参照してください。 SVNのコマンドヘルプ 

svn --help

SVNのコピーコマンドヘルプ 

svn copy --help

コメント

SVNコマンドでブランチを作る方法は非常にシンプルでコマンドを覚えればすばやくブランチを作ったりチェックアウトすることが可能になります。
普段vimなどで開発している人はsvnコマンドを使う方が効率が上がると思います。 実際、OpenPNE開発者はsvnコマンドを使っている人が多くいます。

マージ

マージする方法を説明していきます。

マージは直訳すると、「合併する」「融合する」といった意味がありますが、ここでは、ソースコードとソースコードを融合させることをいいます。
基本的には、先ほどブランチとしてtrunkから派生させたコードをまたtrunkに融合させるという作業をOpenPNEでは使っています。しかし、マージはその他にもさまざまな使い方があります。
例えば、2.10.0から派生した個人作業ディレクトリのブランチでのんびり機能追加を開発していたが、trunkが2.11.6になっていたときに、その追加機能をtrunkに取り込んでも動かないということがないように、ある程度trunkの開発が進んだときに、個人作業ディレクトリにtrunkをマージさせておけばtrunkにマージさせたときに現在のtrunkのバージョンと相性が悪いから動かないということがなくなります。

マージは基本的に、あるリビジョンからあるリビジョンでの変更箇所を取り込む作業になります。ファイルをそれぞれ変更するのではなく、修正されている箇所だけ取り込むという作業です。

それでは、ブランチと同じく、「TortoiseSVNでマージする方法」と「SVNコマンドでマージする方法」の2種類を紹介します。
マージにはさまざまな種類がありますが、ここでのマージは、個人のローカル作業用ディレクトリにTrunkの変更箇所をマージする方法を紹介します。

TortoiseSVNでマージする方法

「TortoiseSVNでブランチを作る方法」と同じく、TortoiseSVNを使ってマージしていきましょう。

マージ

まず、TortoiseSVNでマージする方法ですが、先ほどのブランチでの使い方同様TortoiseSVNのメニューは右クリックをすることでメニューを開くことが出来ます。 今回はマージさせたいディレクトリの上で、右クリックをし、「TortoiseSVN」を選択し「Merge...」を選択します。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/11-merge_migi.png

「Merge...」を選択したらMergeウィンドウが表示されます。 マージをする上で一番分かりにくい点は、このFromとToだと思います。先ほど、「マージは基本的に、あるリビジョンからあるリビジョンでの変更箇所を取り込む作業」の述べましたが、それがここと一致します。このFromとToの間で変更された箇所を取り込みます。URLには、取り込みたい先のリビジョンのURLを指定します。 

From：マージしたい範囲の最初のリビジョン
To:マージしたい範囲の最後のリビジョン

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/12-merge.png

この様にFromとTo指定して、Mergeを押すだけで、そのリビジョン間の変更箇所がローカルの作業ディレクトリにマージされます。

ここで悩む人が多いのが一箇所の変更です。一箇所のリビジョンを変更したいときは、その前のリビジョンから変更したいリビジョンをFromとTo指定に指定します。 例えば、リビジョン5115の修正を取り込みたいときは、画像のように、 

From：5114
To:5115

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/13-merge2.png

SVNコマンドでマージする方法

SVNコマンドでマージする方法を紹介していきます。
それではTortoiseSVNと同じように、リビジョンを指定して変更箇所をローカルの開発ディレクトリにマージしていきます。

マージ

まずは、作業ディレクトリに移動してください。 

co3k@colinux:~/Programming/sns$

次に、SVNのsvn mergeコマンドを使ってマージします。

svn mergeコマンドは下記のように指定します。この-rオプションというのはリビジョン指定をするときには必要なので忘れない様に注意が必要です。
この例を解説すると、trunkの5114から5115の変更点をローカルのprj_remove_globalsディレクトリにマージするという意味になります。 

svn merge -r 最初のリビジョン:最後のリビジョン SVNのURL マージ先のローカルディレクトリ名

例)
co3k@colinux:~/Programming/sns$ merge -r 5114:5115 https://trac.openpne.jp/svn/OpenPNE/trunk/ prj_remove_globals

逆マージ

OpenPNEの開発ではこの逆マージをよく使います。 逆マージとはマージの逆をすることで、SVNで誤った操作などをしたときに修正する方法です。
なぜ、削除ではなく逆マージをするのかというと、記録を残すためです。誰が何をどう変更したかという記録を残すために修正も逆マージをして誰が修正したのかということをログとして残します。
ここでは、TortoiseSVNを用いた逆マージを紹介します。

マージ

マージをするときに、「マージは基本的に、あるリビジョンからあるリビジョンでの変更箇所を取り込む作業」と説明しましたが、このマージの性質を利用して逆マージを行います。
逆マージは、FromとToのリビジョンを変えるだけです。
先ほどのリビジョン5115のマージを失敗して違うところにマージしてしまったというときには。先ほどは、Fromを5114、Toを5115にしていましたが、逆マージはその逆のリビジョンを指定します。 

From：5115
To:5114

この様に、FromとToを逆に指定するだけで、失敗などを取り消す逆マージをすることが出来ます。
また、svnコマンドを使用した場合の逆マージも同じくFromとToを逆に指定するだけで逆マージをすることが出来ます。

(画像　逆マージ)

tags間でのマージ

その他にも、OpenPNE開発でよく使われるのがtags間でのマージです。
簡単にバージョンアップをすることが出来て、便利な機能です。

例えば、ローカルの開発環境にあるOpenPNE-2.10.3をOpenPNE-2.10.4にバージョンアップしたいときに使用すると、非常に簡単にバージョンを上げることが出来ます。

それでは実際にOpenPNE-2.10.3をOpenPNE-2.10.4にバージョンアップする方法を見ていきましょう。

マージ

これまでのマージと同じように、マージしたいディレクトリ上で右クリックしてメニューをだし、Margeウィンドウを出してください。
先ほどまでは、リビジョンを指定していましたが、このtags間でのリビジョンは基本的にHEAD Rebisionです。ですので、ラジオボタンがRebisionに指定されている場合はFrom、To共にHEAD Rebisionに変更してください。
そして、次にURLですが、Fromに前のバージョンのURLを指定し、Toに更新したいバージョンのURLを指定します。
あとは、普通のマージと同じで、「Merge」ボタンでマージしてください。

このとき、Toの「Use"From:"URL(revision range is selectable in the above log dialog)」というチェックボックスが外れていないと、URLを入力できないので注意が必要です。 

例)
From：https://trac.openpne.jp/svn/OpenPNE/tags/stable/OpenPNE-2.10.3/
To:https://trac.openpne.jp/svn/OpenPNE/tags/stable/OpenPNE-2.10.4/

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-2/14-merge_tags.png