ソースコードのバージョン管理の考え方

ソースコードのバージョン管理については、GitやSubversionなどの様々なツールがある。最近導入の検討を行ったが、「そもそもどういう風にバージョン管理をしたいのか」という明確な戦略がないと、ツールの操作と手間に振り回されてしまうと感じた（振り回されたのだが・・・）。

なので、まずはバージョン管理の目的とその戦略についてまとめてみた。


＜バージョン管理の目的＞
バージョン管理の目的は２つあると思われる。

１．マイルストンの設置
　ある時点の安定した状態を記録しておき、いざというときにそこに戻れるようにする。また、そこからどのような作業が行われたのか、差分を確認できるようにする。リリース管理ともいえる。

２．分業の実施
　分業を実施するため、個々人（あるいはチーム）の作業エリアを別々のバージョンとし、最終的にマージを行う。

サウンドノベルのゲーム（かまいたちの夜etc）などをやったことがある人は、ゲームオーバーになった時どの章から再開するのか選べて便利だな、と思ったことはないだろうか(下図参照)。

これは立派なバージョン管理ではないか。①のマイルストンの管理ができていることで、ここまではうまくいっていたのにな～というところから再スタートできる。

ゲームでは分業することはあんまりないと思うが、仮に上記のようなゲームの攻略本を作るとしたら、「オマエはAルートで俺はBルート」のような形で担当を分け、最後にお互いのセーブデータをマージする・・・ということができたらいいだろう。

この時の「お互いのセーブデータ」がつまるところバージョンに当たり、②の目的で使っていることになる。

＜バージョン管理の戦略＞

では、どのような形でバージョン管理を行えばよいだろう。バージョン管理の手法としては、以下２つが考えられ、これはなにもソースコードの管理だけでなく企業の予算立案などでも使われている考え方である。

１．スナップショット型

ある時点での作業内容を保管しておくことで、バージョン管理を行うタイプである。これは、先ほどのサウンドノベル型に近い。

登場するバージョンは基本的に　作業バージョン・リリースバージョンの２種類である。作業バージョンでの作業がひと段落したら、その時の状態をリリースバージョンとして保管するという形式である。

○メリット

作業する場所が一つなので、作業はしやすい。複数機能を開発している場合、いい意味でも悪い意味でも、既存への影響を早めに知ることができる（同じ場で作業しているので）。

×デメリット

性質上ある機能の分だけ切り出すということは難しい。そのため、複数の機能が同時並行的に開発されていて、できた機能は一刻も早くリリースしたい・・・というような環境では不向き。

上記の例だと、機能Bの開発終了段階ではまだ機能Aの開発が終わっていないため、単純に作業バージョンをコピーするのでなく、安定板であるVer1に対し機能Bの変更のみ反映させるといった作業が必要になる。

→大きい機能でも、リリース可能な状態をキープする戦略があるとよいか。

上記点を考えると、開発する機能・納期が明確に決まっているような案件の場合、または特定機能を全員で開発していくような場合に向いていると思われる。

２．ローリング型

作業を始める前に、その作業を行うための箱を作る方式。

○メリット

他の開発の影響を気にすることなく作業できる。それと、万が一やっぱりこの機能やめた、という場合でも作業用のバージョンを消すだけで済む。

×デメリット

他機能がリリースされた際、そのリリース内容を取り込みながら開発を行っていく必要がある。そのため、長期にわたる機能開発の場合取り込み作業が大変。また、他機能の開発で自分の機能に大きく影響を与える変更があった場合、その検知が遅れることになる。

→機能開発のサイクルを一定にする工夫があると運用しやすいか（長短入り乱れると長の開発が割を食う）

上記点を考えると、不特定多数で作業する場合やリリースする機能は作りながら決めるぜ、というような場合に向いている。

以上が、バージョン管理の目的とその戦略についてである。ツールを選ぶ前にこの辺りをよく考えておくと、どんなツールでどういう風に管理するのがいいのか見通しが立てやすくなると思う。