ホームに戻る
出典 :
バージョン管理システム - Wikipedia
関連 :
分散型VCS
目次 :
バージョン管理システム(VCS)とは
ファイルおよびフォルダの変更履歴を保持するシステム。VCSを用いることでファイル・フォルダが
いつ
誰によって
どのように
変更されたのかを追跡でき、
不具合があった場合に以前のバージョンに巻き戻す
ある人が施した変更を上書きしてしまうことを防ぐ
ことができる。
VCSを用いない場合
すべてのバージョンのファイル(またはフォルダ)をそのまま保存することになるため、ディスクを圧迫する
誰かが保存した後に、同じバージョンを保存すると、上書きされたバージョンは(バックアップが無ければ)永久に失われる(図のVer.0.4)
枝分かれしたバージョンがどこから(どの親から)分岐したのかは、別途記録を残しておく必要がある(図のVer.0.5a / 0.5b)
⇒ 運用でカバーする必要がある
バージョン間の比較には、別途Diffツールを用いる必要がある
VCSを用いた場合
リポジトリには「バージョン間の差分」が保持されており、ディスクを無用に圧迫しない
「バージョン間の差分」は履歴(コミットログ)として保存されており、随時比較できるとともに、以前のバージョンに戻すことが可能
誰か(Bさん)が保存(コミット)した後に、同じ個所を変更したものをコミットしようとしても、競合(BさんとCさん)を解決しなければコミットが許されない
⇒ Bさんの加えた変更は履歴として残り、Bさんの変更が上書きされる場合も合理的に解決される
バージョンの分岐(ブランチ)が記録として残り、本流と支流の区別が明確になるとともに、親を特定できる
バージョン間の差異は、ツールに統合された形で履歴とともに参照できる
⇒ 特定のバージョン同士の比較も可能
代表的なVCSの例
分散型VCSについては
分散型VCS
を参照のこと。
名称
ライセンス
特徴
集中型
CVS
フリー
Subversion (SVN)
フリー
CVSの改良版として開発され、現在も広範に用いられている
Visual SourseSafe
プロプライエタリ
MSVSとの連携が重視されている
分散型
Git
フリー
現在最も広範に用いられるVCSのひとつ
Mercurial
フリー
Subversionと共通する簡便なUIをもつ
基本的な手順
プロジェクトの立ち上げ
バージョン管理対象とするファイルの構成を決定する
(後から変更も可能だが、混乱を防ぐためにはこの時点で確定しておいたほうがよい)
1. のファイル(群)をVCSにチェックイン(インポート)し、バージョン管理下に置く
ファイルの編集
(初回のみ)リポジトリから任意の場所にチェックアウトを行う
以後、この場所が「作業コピー」となる
作業コピーを更新(最新版に同期)する
作業コピーを編集する
コミットを行い、作業コピーへの変更をリポジトリに反映する
2. ～ 4. を繰り返す
VCSにおける概念
以後ファイルおよびフォルダをまとめて「ファイル」と称する。
リポジトリ
バージョン管理対象のファイルを保管するディレクトリ。リポジトリの作成は主にプロジェクト管理者が担当する。
すべての作業者が共通で参照し、編集内容を反映する先となる。
チェックイン(またはインポート)
ファイルをリポジトリに登録し、バージョン管理の対象とすること。
チェックアウト
バージョン管理されたファイルをローカルマシンにダウンロードすること。チェックアウトは原則1回でよい。
(以後は更新により、ローカルをリポジトリに同期する)
作業コピー
ローカルマシンにダウンロードした、リポジトリのコピー。
この作業コピーに対して編集を行う。
コミット(またはチェックイン)
作業コピーに加えた変更をリポジトリに反映(確定)すること。これにより、リポジトリ上のファイルが更新される。
変更(コミット)した理由、変更の概要をコミットメッセージとして残すのが一般的。
更新(アップデート)
作業コピーを最新、または指定したリビジョンに更新すること。
ファイルの変更は最新バージョンに対して行うのが原則であるため、
変更前には必ず更新を行うこと
。
(更新処理を行わない限り、ローカルのファイルは自動的には最新化されない)
リビジョン
ファイルの世代を(主に)通し番号で表したもの。これにより、ファイルの世代を特定できる。
コミットによって1つ増え、リビジョンとコミットは1対1で関連付けられる。「バージョン」と概ね同義。
リビジョンを通し番号ではなくハッシュ値で管理するVCSも存在し、その場合はコミット前後でハッシュ値が全く異なるものとなる。
いずれにせよ、リビジョンは一つのリポジトリ内で一意であることが原則。
ログ
リビジョン( = コミット)履歴の一覧。ログを参照することで、どのファイルが、誰によって、いつ、どのように変更されたのかを追跡できる。
ステージング
ファイルをバージョン管理下に置くこと。
作業コピーとなっているフォルダ上にファイルを配置しただけでは、その後コミットを行ったとしてもそのファイルはリポジトリには追加されない。
配置したファイルを「追加」することでバージョン管理下に置かれ(ステージング)、コミットによってリポジトリに反映される。
同様に、ファイルを削除する場合もバージョン管理下から抜く「削除」(ステージから降ろす)処理が必要。
トランク(trunk : 幹) / ブランチ(branch : 枝)
開発を行う上で、系統が枝分かれすることがある。別れた枝のことをブランチと呼び、ブランチ名を設定できる。
対して、主流となる系統(枝分かれの元)をトランクまたはマスター(master)と呼ぶ。
ブランチに対してさらにブランチを作成することができる。また、トランクもブランチである。
(すなわち、トランクを含めたブランチ同士に優劣はない)
タグ
担当者が特定のリビジョン(スナップショット)に対して付与する別名。正式なバージョン名が決定した際などに用いる。
更新などの際には、リビジョン番号だけでなくタグを用いてリビジョンを指定できる。
衝突・競合(コンフリクト)
あるファイルに加えた変更に対して、別の人が同じ個所を変更しておりコミットできないこと。
例えば、AさんとBさんがともにリビジョン1をチェックアウトし、同じファイルの同じ個所に対して変更を行った場合、
先にコミットしたAさんはほかに何も行う必要は無いが、Bさんが遅れてコミットしようとしても、
(Aさんの加えた変更が上書きされることを防ぐため)競合が発生してコミットできない。
この場合、Bさんが取る手順は、
手元のファイルを(Aさんの変更が反映されたリビジョン2に)更新する
(ファイルを編集していた場合)競合の解消が求められるため、
Aさんの変更、自身の変更のいずれか、または両方を残すのかを選択する
(不都合が無いよう、PLやAさんとの合意をとる必要がある)
となる。
競合の解決は(特に慣れないうちは)煩雑で危険を伴うため、そもそも競合が発生しないように、
ファイルの編集は(そのブランチの)最新版に対して行う
(編集前に更新を徹底する)
同一のファイルを複数人で編集しないよう、PLが役割を調整する
担当者ごとにブランチを作成する
とする必要がある。
併合(マージ)
(多くの場合は)あるブランチに、別のブランチとの差分を取り込むこと。
マージされたブランチは、それまで自身に加えられた変更と、取り込んだ別ブランチの変更が混在することとなる。
マージの際には不整合が無いよう両者の比較(および競合の解決)を十分に行う必要がある。
マージ対象はブランチに限らず、特定のリビジョン、またはタグでも可能である。
