バージョン管理システムの種類 — Git・SVN・その他の違い
バージョン管理はいまGit一強だが、会社に入るとSVN（Subversion）のリポジトリが現役だったりする。バージョン管理システム（VCS）の全体像と、GitとSVNの考え方の違いを整理する。
バージョン管理システムとは
ファイルの変更履歴を記録して、「いつ・誰が・何を・なぜ変えたか」を辿れるようにし、任意の時点に戻せるようにする仕組み。複数人が同じコードを触っても壊れないようにする並行作業の交通整理も担う。
最終版_v2_修正済み(最新).zip のようなファイル名運用の正式な解決策、と言えばだいたい合っている。
2つの方式: 集中型と分散型
VCSは歴史的に「集中型」から「分散型」へ進化してきた。
| 集中型（SVNなど） | 分散型（Gitなど） | |
|---|---|---|
| 履歴の置き場所 | 中央サーバーに1つだけ | 全員の手元に完全なコピーがある |
| commitの意味 | 中央サーバーに即反映される | 手元のリポジトリに記録されるだけ（共有はpush） |
| オフライン作業 | ほぼ不可（履歴参照もサーバー必要） | 履歴閲覧・commit・branch全部できる |
| リビジョンの識別 | 連番（r100, r101, ...） | ハッシュ（a1b2c3d...） |
| ブランチ | ディレクトリのコピーとして表現。重い文化 | 軽量。気軽に切って捨てる文化 |
| サーバーが壊れたら | 履歴が失われる恐れ（バックアップ頼み） | 誰かのcloneから復元できる |
- 集中型: 中央に「正」が1つあり、全員がそこに直接コミットする。状態がシンプルで分かりやすい反面、サーバーに繋がらないと仕事にならない
- 分散型: 全員がリポジトリの完全な複製を持ち、手元で自由に作業してから同期する。GitHubやGitLabの「中央リポジトリ」は技術的な必須要素ではなく、運用上そう扱っているだけ（だから手元だけでcommitが完結する）
主なVCSと使われる場面
Git（分散型・現在のデファクト）
- Linuxカーネル開発のためにLinus Torvaldsが作った（2005年）
- ブランチが軽い・速い・オフラインで完結する、が武器。GitHubの登場でOSS標準になり、そのまま業界標準に
- 新規プロジェクトでGit以外を選ぶ理由は今はほぼない
Subversion（SVN。集中型の代表）
- 2000年代の企業開発の標準。歴史の長い社内システムでは現役
- 連番リビジョンが分かりやすい、リポジトリの一部ディレクトリだけチェックアウトできる、ファイルロック（同時編集の禁止）ができる、などGitにない性質もある
- 巨大なバイナリを多数含むリポジトリでは、歴史全部を手元に持たない集中型の方が軽いという事情もあり、あえて残している現場もある
Mercurial（分散型）
- Gitと同時期に生まれた分散型。コマンド体系が素直で、かつてはFacebookやMozillaが採用していた
- 現在は新規採用がほぼなくなり、ホスティング（Bitbucket）もサポートを終了した。「Gitに敗れたもう一つの分散型」として名前だけ知っていればよい
Perforce（Helix Core。集中型）
- ゲーム業界・大規模バイナリアセットの現場で強い商用VCS。数百GBのアセットでも高速で、ファイルロック運用が前提のアート制作と相性がいい
- UnrealEngine系の大規模開発では今も第一線
GitとSVNの対照表
SVNの現場に入ったとき用の読み替え表。同じ単語で意味が違うものがあるのが罠。
| したいこと | SVN | Git |
|---|---|---|
| リポジトリを手元に用意 | svn checkout URL（作業コピーだけ取得） |
git clone URL（履歴ごと複製） |
| 最新を取り込む | svn update |
git pull |
| 変更を記録 | svn commit（即サーバーに反映） |
git commit（手元のみ）→ git push で共有 |
| 状態確認 | svn status |
git status |
| 差分 | svn diff |
git diff |
| 履歴 | svn log |
git log |
| 元に戻す | svn revert |
git restore など |
| ブランチ | svn copy（branches/ ディレクトリへコピー） |
git branch / git switch -c |
| 標準的な構成 | trunk/ branches/ tags/ ディレクトリ |
main ブランチ + ブランチ機能 |
特に注意する差:
checkoutの意味が全然違う。SVNのcheckoutはGitのclone相当。Gitのcheckout（switch）はブランチ切り替え- SVNのcommitは即共有。Gitの感覚で気軽にcommitすると、ビルドの通らないコードが即チームに届く。SVNでは「commit = push」と思って慎重に
- SVNにはステージング（git add）がない。変更したファイルはそのままcommit対象になる
- SVNのブランチはコピー運用なので、Gitのように「1機能1ブランチで毎日切る」文化ではないことが多い。現場のルールに従う
どれを学ぶべきか
- Gitだけで足りる。概念（分散型・ブランチ・マージ）を一度身につければ、他のVCSは対照表レベルの読み替えで対応できる
- SVNの現場に入ったら、上の対照表＋「commitは即共有」「checkoutはcloneのこと」の2点だけ最初に意識する
git svnというブリッジ機能を使うと、SVNリポジトリを手元だけGitとして扱うこともできる（現場のルールが許せば）
まとめ
- VCSは集中型（中央に履歴が1つ）と分散型（全員が完全な複製を持つ）の2方式
- 現在はGit（分散型）がデファクト。SVNは歴史ある社内リポジトリで現役、Perforceはゲーム・大規模アセットの世界で現役
- GitとSVNはcheckoutとcommitの意味が違うのが最大の罠。SVNのcommitは即サーバー反映
- 学ぶ優先度はGit一択。他は現場に合わせて読み替えれば足りる