バージョン管理システムで代表的となっているGit、Subversion、Mercurialだが、それぞれ似たような点を持っている一方で、それぞれ違いがある。ここではGitのコミットIDとSubversionとMercurialのリビジョン番号に着目して少々述べてみたい。
GitのコミットID
Gitではリビジョンではなく、コミットID ((コミット識別子とも)) と呼ばれるコミット情報 ((変更したファイル名やコミッターの情報、コミットメッセージなど)) をSHA1でハッシュしたものがバージョンを識別するIDとなっている。
これは、分散型バージョン管理システムでSubversionのような連番のリビジョンを使うとそれぞれのリポジトリーでの整合性を確保できないからであると考えられる。
これによってそれぞれのリポジトリーで整合性を確保していると考えられるものの、ユーザーにとってはリビジョン番号と比較するとかなりわかりづらいものとなっている。リビジョン番号であれば数字で説明することも可能だが、コミットIDの場合は補助ツールを使わない限りコミットIDを指定するのがかなり面倒だからである、
とはいえ、重要な部分でタグをつけたりすることで、ある程度は面倒さを回避することは可能と考えられる。
Subversionのリビジョン番号
Subversionでは対照的に、リビジョンと呼ばれるバージョンの概念がある。これはSubversionにおけるバージョンを示す識別子だが、Subversionにおいてはコミットされるごとにリポジトリのリビジョン番号が加算されるシステムを採用されている。
分散型バージョン管理システムとは違い、(git-svnやhgsvnなどを使わない限り)バージョン管理を行うのは中央サーバーのみであるため、シンプルなリビジョンで十分であるほか、どのリビジョンかを比較的容易に指定できる特徴がある。
ただし、集中バージョン管理システムではgit-svnやhgsvnなど、ローカルのリポジトリーをgitあるいは後述のMercurialなどで管理するツールを使わない限り、サーバーのリポジトリーが破壊されたら再起不能になるリスクが比較的高い。
Mercurialのリビジョン番号とチェンジセットID
なお、Mercurialは分散型バージョン管理システムだが、Subversionと同じようにリビジョン番号を採用しているが、これはあくまでローカルリポジトリー専用のものであり、グローバルで使うものとしてははGitに近いチェンジセットIDが採用されている。
これによって、ローカルにおいてはリビジョン番号を指定するという使い方ができるという利点があるものの、他のリポジトリーが絡むとそれぞれのリポジトリーでは別のリビジョン番号が割り当てられる可能性が高く、リビジョン番号という意味では整合性を犠牲にしている側面がある。
この点からローカルならSubversionのような使い方がある程度可能で、なおかつGitの分散リポジトリシステムの利点を受け継いでいるように見える。
最後に
それぞれのバージョン管理システムのリビジョン及びコミットIDなどを調べるにつれて、そのバージョン管理システムのあり方の違いから、どういう風に対処しているのかがなんとなく見えてきた気がする。
それぞれのシステムには利点と弱点を持っているので、目的や使いやすさを勘案した上で最も合ったものを使っていきたいところである。
ウェブマスター。本ブログでITを中心にいろいろな情報や意見などを提供しています。主にスマートフォン向けアプリやウェブアプリの開発を携わっています。ご用の方はコメントかコンタクトフォームにて。
