第3章 Subversionベストプラクティス
Authors:YOSHIHARA Hidehiko
新機能開発用ブランチの更新結果を見たO先輩の表情が固まりました。
O先輩●M子ちゃん今コミットしたファイルの中におかしなファイルがあるみたいだけど、確認してもらえるかな？
M子●すみません。関係ないファイルをコミットしてしまいました。すぐに削除します。
O先輩●ファイルを削除するのはよいけど、ちょっとファイル名が気になるね。この「Hoge.java.20070412」というファイルは何に使っていたの？
M子●ファイルをすぐに元に戻せるようにと思って…。
O先輩●ファイルを元に戻すならバージョン管理システムもできるよね。
M子●
リファクタリングをやっていたのですが、変更したあとに前の状態に戻したくなるかもしれないし、
そんなのをコミットしたらみんなに迷惑をかけちゃいそうで。
O先輩●確かに、気持ちはわかるけど、これじゃあローカルにまたバージョン管理を作っているようなものだよ。それも人間が管理する不安定な管理システムでね。
M子●そうですね。個人用にブランチを作成することにします。
O先輩●最後に一括してメインラインにマージすれば、余計なコミットがメインラインに発生しないから、
ほかの開発者に迷惑をかけることはないよ。でも、まぁ、日付を拡張子に付けたM子ちゃんは、まだましなほうかな。
と、O先輩が送った視線の先にはK太君のディスプレイが…。
Hoge.java
Hoge.java.bak2
コピー〜Hoge.java
コピーw〜Hoge.java
実験実装やリファクタリングのように、ある種手探りに似た作業は頻繁に変更が行われるものです。
このように手戻りを行う可能性のあるときこそ、バージョン管理が非常に有効に活用できるのですが、中途半端なコミット履歴を残したくない、ほかの開発者に影響を与えたくありません。
メインラインに影響を与えずにバージョン管理を行いたい場合は、メインラインから隔離した作業環境を作成して、プライベートバージョンと呼ばれる個別用のバージョン管理を行いましょう（図3）。
図3 プライベートバージョン
プライベートバージョンは、個人用のブランチを作成することで手軽に作成できます。ブランチを作成した本人しか触らないようなコードラインであれば、手戻りもソースコードの品質も縛りを受けることはありません（最低限度、コンパイルは通った物をコミットしていただきたいものですが）。
そして、最後に一括してメインラインにマージさせればよいのです。
ただし、メインラインに行われた変更を反映させ続けることは必要です。将来的にメインラインと統合を行う予定で作成を行った物なので、メインラインとの同期を怠るとマージ作業にかかる手間が増えてしまいます。
■svkで隔離された領域を持て
Subversionの場合はブランチを横断してリビジョンが採番されてしまいますので、プライベートバージョンのリビジョンの分だけ抜けが発生したように感じてしまいます。またサーバに接続できず、バージョン管理が行えなくなる状況も考えられます。
K太●そういえば、O先輩も結構リファクタリングをしたり大幅に変更したりする割には、個別用のブランチを作成していませんね。さすがですね。
O先輩● 僕？僕はsvk(注1)を使っているからね。コミット時に余計なりビジョンを削除してくれて、サーバに接続しなくてもバージョン管理をやってくれるのでなかなか便利だよ。
M子、K太●O先輩ずるい。
svkは、ローカルにリポジトリのミラーを作成することで、ネットワーク環境がないところでもでバージョン管理が行える分散バージョンコントロールシステムと呼ばれるものです。Subversionと互換性のあるファイルシステムを使用し、Subversionライクなコマンドが用意されているため導入が容易です。
ミラーリポジトリに対してバージョン管理を行い、1トランザクションにまとめて元リポジトリにコミットを行うことができます。その際ミラーリポジトリに行った変更履歴を除いてコミットを行うこともできます。
注1）http://svk.bestpractical.com/
![[Backlog] - Subversion -](../images/ad-backlog-svn.gif)