「バージョン管理はSVNとGit、どちらを使うべきか」——開発環境の選定や移行の検討で、必ず出てくる問いです。
結論から言えば、この問いに唯一の正解はありません。プロジェクトの特性で決まります。ソースコード中心で分岐の多い開発ならGit、巨大なバイナリを含む資産を厳格に統制したいならSVN。どちらかが「新しくて優れている」のではなく、設計思想が違う道具です。
この記事では、両者の違いを仕組みから整理し、どちらを選ぶべきかを判断するための基準を示します。私たちはSVNとGitの両方をホスティングサービスとして10年以上提供しており、どちらかに誘導する意図なく、現場で見てきた実態をもとに書きます。
仕組みの違い：集中型と分散型
最大の違いは、履歴をどこで管理するかです。
集中型（SVN）と分散型（Git）の構造の違いを示す
SVN（集中型）は、サーバー上のリポジトリがただ一つの「正」です。開発者は必要なファイルだけを手元に取り出し、変更を直接サーバーへコミットします。履歴はサーバーに一元化され、リビジョン番号はプロジェクト全体で連番になります。
Git（分散型）は、開発者全員がリポジトリの完全な複製（全履歴込み）を手元に持ちます。コミットはまずローカルに記録され、任意のタイミングでサーバー（リモートリポジトリ）と同期します。オフラインでも履歴を操作でき、分岐（ブランチ）の作成・統合が高速です。
この設計の違いが、得意・不得意のすべての源泉になっています。
比較表：8つの観点
| 観点 | SVN | Git |
|---|---|---|
| 管理方式 | 集中型 | 分散型 |
| 履歴の所在 | サーバーに一元化 | 全員が複製を保持 |
| リビジョン | プロジェクト全体で連番（r1024） | コミットごとのハッシュ値 |
| 部分取得 | ディレクトリ単位で可能 | 原則リポジトリ全体を複製（※） |
| 大容量バイナリ | 強い（必要分だけ取得） | 肥大化しやすい（LFS等で補う） |
| ブランチ・マージ | 可能だが重め | 高速・日常的に使う前提 |
| 権限管理 | ディレクトリ単位で細かく統制可 | リポジトリ単位が基本 |
| 排他ロック | 得意（lockで編集を直列化） | 不得意（分散モデルと相性が悪い） |
※Gitにも部分的に取得する仕組み（sparse-checkout等）はありますが、運用は複雑になります。
補足すると、SVNが変更のたびに「r1024」のような連番でバージョンを示すのに対し、Gitは「a3f5c9…」のような英数字の文字列（ハッシュ値）でコミットを識別します。連番のほうが「どちらが新しいか」を直感的に把握しやすく、監査で版を指し示すときにも扱いやすい、という違いがあります。
Gitが向いているプロジェクト
- ソースコード中心の開発：テキストファイルの差分管理・マージは、Gitの独壇場です
- 分岐の多い開発スタイル：機能ごとのブランチ、プルリクエストによるレビュー、頻繁なマージを回す現代的なワークフローは、Gitを前提に設計されています
- 多拠点・多人数の分散開発：オープンソース開発のように、ネットワークやサーバーに依存せず各自が作業を進める形態に強い
- CI/CDとの統合：周辺ツールのエコシステムが豊富で、新しいツールはまずGit対応から始まります
SVNが向いているプロジェクト
- 巨大なバイナリファイルを含む資産：制御ソフトの成果物、ファームウェア、3Dモデル・音声・動画アセット、Excelで管理される設計文書など。Gitは全履歴を各端末へ複製するため、こうした資産では現実的でなくなります。SVNは必要な分だけ取得でき、数百GB〜TB級でも運用できます
- 厳格な権限統制が必要な組織：ディレクトリ単位でアクセス権を設定し、サーバー側で一元統制できます。部門・取引先ごとに見せる範囲を変える運用は、SVNが得意です
- 「同時編集できないファイル」を扱う現場：Excelやバイナリの設計データはマージできません。SVNの排他ロックなら、「編集中は他の人が触れない」を仕組みで保証できます
- 監査証跡として履歴を使う現場：連番リビジョンとサーバー一元管理は、ISO 26262等の構成管理・ベースライン管理や、監査での証跡提示と相性が良い設計です
- 長期保守資産：何年も動き続けるシステムの保守では、既存のSVN履歴そのものが資産です。動いている管理基盤を無理に乗り換える必然性はありません
「Gitへ移行すべき」とは限らない3つの理由
世間では「これからはGit」と言われて久しく、たしかに新規のソースコード開発ではGitが主流です。しかし、SVNで運用中の資産を抱える企業がGitへ移行すべきかは、別の問題です。
- 移行コストとリスクが、利益を上回ることが多い。数百GBの履歴・数百人の利用者・確立した運用ルールを移し替えるコストに対し、得られるのは主に「ブランチが速くなる」こと。バイナリ中心の資産なら、移行後にかえって扱いにくくなります
- バイナリ資産はGitに移しても幸せにならない。Git LFSなどの補助手段はありますが、運用は複雑になり、SVNの「必要な分だけ取得」のシンプルさには届きません
- 履歴は監査資産である。長年積み上げたリビジョン履歴は、品質保証・監査対応の証跡です。移行ツールで完全に引き継げるとは限らず、欠損リスクを取るだけの理由が必要です
つまり、SVNを使い続けるのは「技術的に遅れている」のではなく、資産の性質を踏まえた合理的な判断であるケースが多いのです。詳しくは「Subversion（SVN）とは？仕組み・Gitとの違い・今も製造業で使われる理由と安全な運用方法」で解説しています。
現実解：SVNとGitの併用
実際の現場では、「どちらか一方」ではなく併用が現実解になることが増えています。
- ソースコードの新規開発はGit
- 設計文書・バイナリ成果物・長期保守資産はSVN
このとき問題になるのが、管理基盤がバラバラになることです。権限管理・バックアップ・監査対応をサービスごとに二重整備するのは、情報システム部門にとって大きな負担です。SVNとGitを同じ基盤・同じ権限体系で扱えるサービスを選ぶと、この負担を解消できます（私たちのtracpathも、SVN・Gitの両方を同一プロジェクト内で扱える設計にしています）。
併用体制の具体的な作り方は、別の記事（公開予定）で扱う予定です。
まとめ
- SVNとGitは「新旧」ではなく設計思想の違い。集中型と分散型、それぞれに向く現場が異なります
- ソースコード中心・分岐の多い開発はGit。大容量バイナリ・厳格な権限統制・監査証跡・長期保守はSVN
- すでにSVN資産がある場合、移行の判断は「流行」ではなく移行コスト・リスク・資産の性質で行うべきです
- 併用する場合は、管理基盤を一元化できるかが情シスの負担を分けます
SVNもGitも、ひとつの基盤で
tracpathはSVN・Git両対応のクラウドホスティング。国内サーバー・ISMS認証・ディレクトリ単位の権限管理で、併用体制をひとつの基盤に集約できます。
→ 無料で試す ／ → 運用のご相談はこちら
関連記事
この記事の著者
株式会社オープングルーヴ ／ tracpath編集部
2004年よりソフトウェア開発の現場を支援。SVN・Gitのクラウドホスティングサービス「tracpath」を提供し、製造業・業務システム開発企業のバージョン管理・移行を多数支援。ISMS（ISO 27001／27017）認証取得。
No Comments