この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "バージョン管理システム" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2020年6月）

バージョン管理システム（英: 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]。