本記事を書くに至った背景
Subversion や Git を ファイルを共有するためのツール と思っている人がいたので、そうではなく ファイルのバージョン管理を行うためのツール であること、またバージョン管理を行う目的をまとめることにした。
バージョン管理を行う ( 主な ) 目的
バージョン管理システムを使う ( 主な ) 目的は下記の 4 つだと思う。
以前の状態に戻る
変更履歴を調査する
プロジェクトを管理する
変更者と変更理由を知る
以下で順を追って説明する。
1. 以前の状態に戻る
ソースコードを編集していると、「変更を行う前の方が良かった」「誤って変更してしまったので元に戻したい」ということが多々ある。バージョン管理システムは以前の状態に戻る手段を提供しているため、本目的を容易に実現することができる。
古典的なバージョン管理
目的 1 を実現するだけなら、バージョン管理システムを使わなくても実現可能である。例えば、hoge.cpp を編集する前にファイルのコピー ( hoge_copy.cpp ) を作成しておき、「変更前の方が良かった」と思った時点で、 hoge_copy.cpp の内容を hoge.cpp にコピーして編集内容を取り消すといった具合に。しかし目的 2 〜 4 を古典的な方法で実現するのは至難の業である ( 場合が多い ) 。
2. 変更履歴を調査する
編集内容を全て破棄して編集前の状態に戻るのであれば、古典的な方法でも十分可能であるが、「〇〇の部分だけ編集前の状態に戻したい」といった場合は古典的な方法では難しい。
バージョン管理システムを使っていれば、変更履歴の調査 / 各変更で何が変わったのかを調査し、特定部分の変更のみを容易に取り消すことができる。
3. プロジェクトを管理する
ソフトウェア開発では単一ファイルではなく複数ファイルを扱うことが普通である。例えば「 hoge.h に新規メンバ関数の宣言を追加し hoge.cpp でその実装を追加した」といった、複数ファイルにまたがる論理的な 1 つの変更を 1 つの単位として扱いたい場合、古典的な方法では難しい。バージョン管理システムは「コミットはアトミックである」という特徴を有するため、本目的を容易に実現することができる。
4. 変更者と変更理由を知る
自分が編集しているファイルに意図が不明な 1 文があったとする。自分にとってその 1 文は意図が不明でも、何らかの意図を持って入れられたはず。バージョン管理システムの変更履歴を辿ることで、変更者と ( 記されていれば ) 変更理由を知ることができる。変更履歴から意図が分からなかった場合は、直接変更者に確認することもで意図を知ることができる。
まとめ
Subversion や Git は ファイルのバージョン管理を行うためのツール であり、バージョン管理を行う ( 主な ) 目的は
以前の状態に戻る
変更履歴を調査する
プロジェクトを管理する
変更者と変更理由を知る
ためである。