バージョン管理システム
 |
バージョン管理システム（英: version control system、VCS）はコンピュータ上でファイルの変更履歴を管理するシステムである。
概要
[編集]ソフトウェアソースコード・ドキュメント・画像・音楽など、様々な電子ファイルは段階を経て編集される。編集の過程で履歴を保存しておけば、何度も変更を加えたファイルであっても過去の状態や変更内容を確認したり変更前の状態を復元したりできる。バージョン管理システムの基本的な機能は、このファイルの変更内容・作成変更日時の履歴保管である。
また編集は複数人により同時並行でおこなわれる場合もある（例: 商業的なソフトウェア開発、オープンソースプロジェクト）。複数の人間が複数のファイルを各々編集すると、それぞれのファイルの最新の状態がどれであるか分からなくなったり、同一ファイルに対する変更が競合（コンフリクト）したりするなどの問題が生じやすい。バージョン管理システムはこのような問題を解決する仕組みを提供する。
バージョン管理システムの利用は大まかに以下の過程を経る。
- (初回のみ）管理対象をまとめたリポジトリの作成
- 編集希望バージョンのファイル取得（チェックアウト）
- 編集
- 編集内容のリポジトリ反映（コミット）
この過程を繰り返すことで編集履歴がリポジトリへ蓄積する。例えばA→B→Cとコミットした上で過去のバージョンBに戻りたくなった場合、Bのチェックアウトでそれが実現できる。このチェックアウト後に編集をおこないコミットした場合、Cが上書きされるのではなくバージョンC"が新たに生成される（B→C"という分枝:ブランチ）。このような仕組みによりバージョン管理システムはユーザーのバージョン管理を補助する役割を果たしている。
歴史
[編集]バージョン管理システムの前身は、おそらく1962年のIBMのOS/360 IEBUPDTEソフトウェア更新ツールにまでさかのぼることができる。ソースコード管理用に設計された完全なバージョン管理システムは1972年の、同じくOS/360用のSCCSである。1975年12月4日に公開されたSCCSの前文は、歴史的にそれが最初の本格的なバージョン管理システムであることを示していた[1]。その直後にRCSが発表され[2]、ネットワークに対応したCVSが続いた。CVSの次世代としてSubversionが登場し[1]、さらにGitなどの分散型リビジョン管理ツールが登場した。[3]
機能
[編集]バージョン管理システムはその要件に合わせ以下の機能のいずれかを提供する。
- コンテンツ履歴
- 変更記録（create & update = commit, revert）
- コンテンツ取り出し・復元（read = checkout）
- 履歴削除（delete = reset）
- メタデータ履歴
- 記録日時
- commitメッセージ
- タグ
- 並行開発
- ファイルロック
- ブランチ&マージ
管理方式
[編集]バージョン管理システムでは、ファイルの各バージョンをデータベースに保持しており、このデータベースを一般にリポジトリと呼ぶ。
バージョン管理システムの基本的な利用方法は以下の流れになる。
- ファイルをリポジトリに登録する。
- ファイルをリポジトリからローカル環境に取り出す（チェックアウト）。
- ローカル環境で、ファイルに対し変更を行う。
- 変更したファイルをリポジトリに書き戻す（チェックイン）。
ファイルがチェックインされると、システムによって「いつ」「誰が」「どんな変更を行った」等が記録され、後から参照できる。また必要に応じて古い版を取り出すこともできる。
これらを行うユーザインタフェースは、CUIやGUIなど様々である。また、統合開発環境を組み合わせて使用できるものもある。TortoiseSVNやTortoiseGitなどのように、オペレーティングシステムのシェル環境と統合されて直感的に利用できるGUIフロントエンドも存在する。
リポジトリ
[編集]バージョン管理におけるリポジトリはバージョン管理対象の集合（データベース）である。コンテンツの全履歴・メタデータ履歴などで構成される。ファイルの編集がリポジトリへコミットされるとリポジトリ内に新たな履歴が記録される。
レポジトリの管理方法は2つに大別される。
- 集中型バージョン管理（英: Centralized Version Control）: プロジェクトの中央レポジトリを全員が編集[4]
- 分散型バージョン管理（英: Distributed Version Control）: プロジェクトの完全なレポジトリを各自が保有[5]
分散型バージョン管理システムではレポジトリをコピーすることをcloneと呼ぶ[6][7]。
チェックアウト
[編集]ファイルはシステム固有の形式でリポジトリ内に格納されている。リポジトリから特定バージョンの生ファイルを取り出すことをチェックアウトと呼ぶ[8]。
CVSやSubversionではリポジトリから初めてデータを取り出しローカルに保存することをチェックアウトと呼ぶ。それ以降に再度、他の誰かによって更新されたリポジトリからデータを取り出してデータを最新版に保つことはチェックアウトとは呼ばず、アップデートと呼ぶ。
Visual SourceSafe (VSS) では、リポジトリからファイルを取り出すだけでなく、さらにそのファイルにロックをかけてチェックアウトした人がそのファイルをチェックインするまで他の人が編集できないようになることをチェックアウトと呼び、CVSやSubversionとはチェックアウトの定義が若干異なる。ただし、VSSはソフトウェアのバージョンや設定次第でロックをかけないようにすることもできる。
リポジトリからチェックアウトした後は、しばらくの間にだれかがリポジトリに最新版のデータをコミット（チェックイン）している可能性があるので、コンフリクト、衝突を避けるためにチェックアウトしたデータでの作業を始める前やコミット（チェックイン）する前に、必ずローカルをアップデート（VSSではリフレッシュと呼ぶ）して常に最新版の状態に保つことが推奨されている。
チェックイン
[編集]リポジトリにファイルを書き込むことを、チェックインやコミットと呼ぶ。VSSでは、チェックアウト時にファイルにかけたロックを解除し、他の人が編集可能な状態に戻す。
ロック方式とコピー・マージ方式
[編集]ひとつのファイルへ異なる変更が同時に行われる（並行処理）と一貫性が保てない。この問題を防ぎ並行開発を可能にするために「ロック」あるいは「コピー・マージ」が用いられる。バージョン管理システムはこれらの技法を用い並行開発を可能にする。
ロック方式では、ユーザーは編集するファイルにロックをかけ、他のユーザーが編集できないようにし、編集が完了したらロックを解除する。単純で確実な仕組みではあるが、他のユーザーはファイルの編集完了まで待たされ、効率が悪い。また、ユーザーがファイルにロックをかけたまま誤って放置する恐れもある。ロック方式の考え方は「競合を起こしうる変更は事前に許可しない」である。
コピー・マージ方式では、編集するファイルをシステムからユーザーの元にコピーし、このコピーを編集する。編集完了後に変更した部分をシステム側に反映させるが、この作業をマージと呼ぶ。他のユーザーの編集中でもシステムからのコピーは自由に行えるようにすることで、複数のユーザーが同時に編集作業を進められるため、グループでの利用に向いている。ただし、それぞれのユーザーによる変更が競合する場合には、マージする時点で解決する必要がある。一般的には、変更内容が競合する旨をユーザーに知らせ、内容を確認、修正させる方法がとられることが多い。コピー・マージ方式の考え方は「実際に競合したらその時に解決する」である。
プレーンテキスト形式のファイルは差分管理がしやすいため、マージや競合状態の解消をすることは比較的容易だが、バイナリ形式のファイルは一般的にマージや競合状態の解消が難しい。そのため、既定ではコピー・マージ方式であっても、特定のファイルは常にロック方式とすることのできる機能を持っているバージョン管理システムもある[9]。
バージョン番号、タグ、ブランチ
[編集]バージョン管理システムを利用する場合、ファイルに対してバージョン（リビジョン）番号が付加される。RCSやCVSの場合、通常は1.1から始まり、ファイルの編集が行われる毎に最後の数値がインクリメントされる。その後は、何も指定せずにファイルをチェックアウトした場合、最新のファイルを取り出すことになるが、このバージョン番号を利用することによって、以前に編集したファイルを取り出すこともできるようになる。システムによっては、バージョン番号だけでなく、日付、時刻によってファイルをチェックアウトすることも可能になる。
タグとは、バージョン管理番号とは別に、ファイルに対して特定の名前を付与することである。特に、リポジトリ内のファイルに対して一括したタグをつける[10]ことによって、特定のリポジトリの状態を簡単に取り出すことができるようになる。 ベータ版・リリース版・移植版など、プロジェクトの区切りがついた時点でタグをつけることがよく行われている。
ブランチは、リポジトリを分岐させることで、プロジェクトを分岐させ、複数の方向に開発を並行して進めることができる。大規模な開発プロジェクトで、「開発版」「安定版」とプロジェクトの方向性をわけたいときには有効である。バージョン管理システムの中には、複数の方向にわかれたブランチをまとめる機能をもつものもある。
ネットワークの利用
[編集]グループでバージョン管理システムを利用する場合、ネットワークの利用が必須となる。システムにより固有の方法があるが、大抵は、他の認証システムを利用してユーザーの認証を行ったり、通信経路を暗号化することで通信の安全性をはかることになる。通信は、sshを利用して安全性を確保するのが一般的である。
他に、匿名のシステムを用意しているものもある。インターネット上でプロジェクトを公開している場合に良く用いられ、これにより、開発途中のソースコードをプロジェクトに参加していない人たちに対しても公開している。
関連項目
[編集]脚注
[編集]- ^ a b Collins-Sussman, Ben (2004). Version control with Subversion. Brian W. Fitzpatrick, C. Michael Pilato (1st ed ed.). Sebastopol, CA: O'Reilly Media. ISBN 0-596-00448-6. OCLC 56018869
- ^ Tichy, Walter F. (1985). “Rcs — a system for version control” (英語). Software: Practice and Experience 15 (7): 637–654. doi:10.1002/spe.4380150703. ISSN 1097-024X.
- ^ Loeliger, Jon (2012). Version control with Git. Matthew McCullough (2nd ed ed.). Beijing: O'Reilly. ISBN 978-1-4493-4505-1. OCLC 812195138
- ^ "Centralized Version Control Systems (CVCSs) were developed. These systems ... have a single server that contains all the versioned files, and a number of clients that check out files from that central place." git 2020-10-30閲覧
- ^ "Distributed Version Control Systems ... clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history." git 2020-10-30閲覧
- ^ "you clone a repository from another computer." git 2020-10-30閲覧
- ^ "既存の Git リポジトリ ... のコピーを取得したい場合に使うコマンドが、
git cloneです。...「"checkout" じゃなくて "clone" なのか」と気になることでしょう。 これは重要な違いです。ワーキングコピーを取得するのではなく、Git はサーバーが保持しているデータをほぼすべてコピーするのです。 そのプロジェクトのすべてのファイルのすべての歴史が、デフォルトではgit cloneで手元にやってきます。" git 2020-10-30閲覧 - ^ "Updates files in the working tree to match the version in the index or the specified tree." git 2020-10-30閲覧
- ^ ロック | TortoiseSVN
- ^ しばしば「タグを打つ」ともいう。
| 括弧内の年は正式バージョンのリリース年。†の製品はリリース終了、もしくは更新が長期間途絶えている製品。 | ||||||
| ローカルのみ |
|  | ||||
| C/S型 |
| |||||
| 分散型 |
| |||||
| 概念 | ||||||