プログラムのバージョン管理紹介

2014/10/27

こんにちは。
開発部の齊藤です

今回はちょっと視点を変えてプログラムを書く場合のバージョン管理をちょっと紹介したいと思います
基本的なことで、別にこのツールをつかいましょうとかそういう話じゃないです

ファイル名のバージョン管理

デザイナーの方でバージョン管理と言えばこういう、ファイル名に以下のことをした経験無いでしょうか？

・v001、v002、_finalなどバージョン名を付ける
・20140406のような日付を付ける

ファイル名に特定のバージョン名を付ける時には、手付けだったり、内製ツール、
またはSHOTGUN、TACTICといったアセットマネージメント機能を有するものが行うこともあると思います

プログラムを書くのにどのようにバージョン管理するのか。
同様にソースファイルに同じようにファイル名にバージョンを付けるか?

例えばPythonで、hogeモジュール(ファイル)をimportして使用していた場合を考えます

import hoge

もし、hogeモジュール(ファイル)のバージョンを変えたとhoge_v002など変えてしまったら
このモジュールを使用している箇所に関して全て下記の変更をする必要があります

import hoge_v002

使用している箇所が複数個所に渡ることはよくあり、これだけでもファイルが増えた時に大変です。
複数の人が同じファイルを同時に編集することもあります。こうなってくると誰が最新なのか。
v002で動くことが保障も出来なくなります。

編集したファイルを統合する必要があります。
共有ファイルとの差を確認して、変更箇所を修正して、上書きとなるでしょう。
結構大変そうです。また、修正中に誰かが共有ファイルを変更したい時は恐らく待つことになるのでしょう。

ファイルベースではなく、安全に効率よくバージョン管理をするにはどうすれば良いか？
バージョン管理システムというのを用います。

バージョン管理システム

バージョン管理システムは、いつ誰が何を変更したのかなど、ファイルの変更履歴を管理するシステムです。
主なソフトとしてオープンソースではSubversion、Git、Mercurial、Bazaar
製品ではPerforce、Alienbrainなどが上げられます

バージョン管理システムはファイル名を使わずにバージョン管理どうやっているのか？
ここではGitを例に紹介します。

Gitでは変更をコミットと呼びます。

コミットには、いつ誰が何をどのような変更(編集、追加、削除など)が行ったのかなど記録されています
コミットには、40文字のIDが付けれられています。このIDがバージョン番号みたいなものです。

コミットで変更を管理するので、バージョンごとにファイル名を付けることがありません。
コミットのID1つ1つがバージョンになります。コミットした時の状態へはいつでも戻れます。
なので、思い切った変更をして結果が悪い場合、すぐに戻って再スタートが出来ます。

動かなくなっても、コミットのログが辿ることで、いつ何の変更が行われたのか分かるのでエラー対応もしやすくなります。

コミットには、コメントが付けられます。何の変更なのかファイルの変更を見なくても分かるようにできます。
コミットを他の人と共有することで、誰がどんな変更したのか認識することが可能になります

ファイルの統合はどうするのか？ コミット同士を見て、ほぼ自動で統合されます。
自動で判断できないものは、ユーザが手動で統合しますが、そこはファイルに目印が書いてあり、それを元に編集していきます。
ここは手動だったり、支援ツール使うなど方法があります。

どのシステムを使うか

使用するバージョン管理システムはどれを採用するか？というの様々な基準があると思います。
バージョン管理システムの情報は多いか？ 使える人が側にいるか？ GUIはあるか？
でも重要なのは、”どのようにツールを作り、管理するのか”だと思います

ここで重要になってくるのがリポジトリというものの扱いです。
リポジトリは、全ての変更履歴情報を持つ所です。何がいつどんな変更があったのか、全ての情報が入っています。
リポジトリの扱いは大きく分けて2つあります。集中型と分散型です。

集中型:
主なソフト: subversion, perforce
開発者全員で共有するリポジトリを1つだけ持ちます
コミットした内容は必ず全員に共有されます。なので、常に最新の状態を保つことが可能です
1つのリポジトリで管理されるので、誰がどこを見れる見れないなど、細かなアクセス制御が可能です。
ただし、リポジトリにアクセス出来ないと過去の変更を引き出したり、変更を反映出来ません。

分散型:
主なソフト: Git, Mercurial, Bazaar
リポジトリを各開発者全員が持ちます。なので、変更内容は全て開発者の環境にあります。
リポジトリはローカルにあるので、引き出したり、変更を反映出来ないということはありません。
ただし、集中型に比べてアクセス制御については弱いです。

コミットの共有はどうしているのか？というと、開発者全員で取り決めた場所のリポジトリと同期することで行われます。
同期しない限り、開発者全員に共有されないため、気軽にコミットしたり消したりすることが可能です。
反面、開発者が同期しない限り変更が共有されないので、いつまで経っても変更が無いということもあります。

どちらが良いのか？というとどちらもメリット/デメリットあるので、こちらが良い!というのは言えません。
いくつか触ってみたり、書籍や公開されているスライドをみて、合うもの選ぶと良いと思います。

最後に

バージョン管理システムは、複数人で長期など規模があがるにつれてその効果を発揮します。
ただそのような状況でないと必要なものじゃないか？というとそうではありません。
1人であっても、いつ何を変更したのかを随時記録し、いつでも戻れる環境を作ることで
安心して変更が出来るようになるというのは、効果があると思います。

また、バージョン管理システムで管理できるのはプログラムだけか？というとそうではありません。
ファイルであれば何でも管理できます。設定ファイルや共有のスクリプト置き場などを管理させることで
設定ファイルを編集して動かなくなった時、スクリプトを間違えて消したときなど
そういうトラブルシュートでも活躍します。

なので、小さな所からどんどん使ってはどうでしょうか？
ではまた!