SVN (Subversion) vs. Git 選定アプローチ

PROGRAMMING

この記事はソフトウェアのソースコードのバージョン管理システム（VCS: Version Control System、もしくはSCM: Source Code Manager）のツールを選定するにあたり、SVNとGitのどちららを選ぶと良いかを自分なりに調べたものです。

ただ、私の環境ではSVNを使用するプロジェクトが多いです。ですが、ネットのトレンドとしてはGit（というかGitHub）が主流で、AtlassianのJiraやAzure DevOps Servicesでもそちらが標準のリポジトリとなっています。そのため、「SVNからGitに乗り換えるべきだろうか？　乗り換えるとすれば、どんな利点があるか？　SVNのままでも問題ないか？」という関心でアプローチしています。念のため補足しておきます。

結論としては、ありきたりかもしれませんがケースバイケースだと思います。ネットの記事では「絶対にGitのほうがよい」とか「GitはSVNの上位互換」と結論している記事が見受けられますが、そうとも言えないと思います。プロジェクト毎に適宜判断すべし、でしょう。SVNはアーキテクチャーがシンプルだし、ある程度の規模のソフトウェアをコンポーネント単位で担当を分けるような開発体制をしている場合、合う気がします。わざわざGitを覚える学習時間も必要ありませんし（時間もリソースなので）。プロジェクトごととアーキテクチャーの違いを踏まえて考慮すべき、というところでしょうか。

SVNとGitの違い： 中央管理 or 分散管理

ググれば分かりますが、両者（GitとSVN）の最大の相違点はリポジトリの管理方法です。SVNは中央管理的、Gitは分散管理的です。

SVNはコード（やファイル）の変更履歴を中央集権的に管理しているサーバーがあって、開発に参画するプログラマーは任意のファイル（やフォルダ）をローカルに同期させ（チェックアウト）、ロックを取得して排他的に編集を行い、最後にコミットをしてSVNサーバーに反映させます。

Gitは中央リポジトリをベアリポジトリ（bare repository）として作成できます。中央リポジトリのソースをプログラマーが取得する場合、git cloneでリポジトリ全体のクローンをローカルに作成した上で作業をします。文字通りの分散管理です。*

中央管理と分散管理という違いは簡単に理解できると思います。ついでに、開発の背景と歴史も少し掘り下げて見てみます。ツールを導入する際は設計思想というか背後の考え方を知ることも重要と思いましたので。

*： SVNのようにソースの一部を部分的に取得（clone）することもできるようですが（sparse-checkout）、執筆時点のGit最新バージョン（2.35.0）でも未だに実験的な機能です。 “THIS COMMAND IS EXPERIMENTAL. …”とあります。
公式ドキュメント：Git – git-sparse-checkout Documentation

Git

最初期のGit開発を主導したのはLinuxカーネル開発で知られるLinus Torvaldsなのは有名ですが、『実用 Git』（Jon Loeliger著）によると、そのLinusか考える理想的なVCSの機能・特徴は以下の通りであると書かれています。

  • 分散開発を容易にすること
  • 何千人の開発者をも扱えること
  • 高速で効率よく動作すること
  • 完全性と信頼性を維持すること
  • 説明責任を強制すること
  • 不変性
  • アトミックなトランザクション
  • 分岐した開発に対応し後押しすること
  • 完全なリポジトリ
  • すっきりとした内部設計

多数の開発者が世界中にいて開発に参画するというLinuxカーネル開発の状況を考えれば、上の2点（分散開発の容易性、何千人の開発者）は特に重要なポイントであるように思います。Gitというツールのコンセプトというか設計思想は、世界中に非常に多数の開発者が散在し関与しているという状況でのOSS開発を意識し設計されている、というのがポイントの一つでしょう。そう考えれば、Gitが管理の方法として分散管理型 (distributed)の形態であるのも納得できます。モジュールごとに担当者を分けるやり方というより、別々の開発者がプログラムの同じ個所を見て、レビューをするなり開発に関与することになります。

SVN (Subversion)

SVNのアーキテクチャーはシンプルです。リポジトリを中央管理するSVNサーバーがあり、各開発者はそのサーバーからソースを部分的（もしくは全体）を取得し、開発作業を行います。

公式サイトでも書かれている通り*、CVSの改良版として開発された経緯があります。CVSの使用経験はありませんが、Wikiや公式サイトを見る限り、ソースコードのファイルを履歴管理してクライアント／サーバーシステムで使えるようにする…というシンプルというか素朴な発想で作られているように思います。ですが、ファイルの変更・削除の扱いに難があったそうで、それらの弱点を克服したものとしてSVN (Subversion)が作られた…そうで。

GitはSubversionに比べ、バージョン管理のモデルが複雑であるとも書かれています。** バージョン管理の仕組みとしてシンプル・分かりやすい、というのはSVNの特徴の一つと言ってよいと思います。

また、現在も開発中でApacheソフトウェア財団により管理・開発されています。

*：”Apache Subversion is a full-featured version control system originally designed to be a better CVS.” (Apache Subversion Features)

**：”The downside is that distributed version control is an inherently more complicated model, which can present a non-negligible challenge to comfortable collaboration.” (Version Control with Subversion [DRAFT])

トレンドはGit

Googleトレンド

Googleトレンドで見るとGitがよく検索されていることが分かります。但し、Googleトレンドの見方としてはあくまで「Google検索に基づいたデータでしかない」点には注意が必要で、世の中のソフトウェア開発全般で主流だと安易に結論するのは早計です。ですが、参考になる情報ではあります。

GoogleトレンドによるSVN、Git、GitHubのトレンド推移の比較

ちなみに、GitとGitHubのトレンドの推移が同じような傾向を示しているので、GitHubによってGitが有名になった…という見方もできるかもしれません。

クラウド系プロジェクト管理ツールはGitHubに標準対応

AtlassianのJira、Backlogなどのプロジェクト管理ツールではGitHubを標準でサポートしています（前者は標準というか無料の公式アドオンだけど）。また、使用経験はありませんがMicrosoftのAzure DevOpsでもGitをサポートしています（Team Foundationバージョン管理も可能らしいですが）。有名どころのクラウド系PJ管理ツールはGitHubに標準対応していて、そういう意味ではGitはやはりこれからのスタンダードである気はします。

ちなみに、オンプレで使用できるOSSでは有名なRedmineはSVN、Git両方に標準対応しています。

SVNの開発は今も継続されている

本記事執筆時点でのSVNの最新版は1.14.2で、これは2022/04/12にリリースされています。*
ですので、別にSubversionはもうメンテナンスされていないから使えないとか、古くて使い物にならない…ということはないはずです。

*：Apache Subversion

改めて整理

GitとSVNどちらを選定するか、ポイントとしては、

  1. 開発プロジェクトのエンジニアがどちらを使えるか
  2. 当該の開発プロジェクトで目下使用してるのはSVNかGitか
  3. 開発体制

で判断する感じでしょうか。
「Gitを使いたい」のなら、そもそもGitを使えばいいです。既に決まってるならその一択しかありません。

上の2つは「学習にリソースを割くべきか？」に集約されるのかなと思います。時間も開発において考慮すべき重要なリソースですので、SVNによるソース管理でも何も問題ないのであればわざわざ不慣れなGitに乗り換えるメリットはないかもしれません。

３番目の開発体制については、例えば基幹系システムのスクラッチ開発やパッケージ開発のようにそれなりに大規模なソフトウェア開発プロジェクトの場合、プロジェクト内でシステムの各部分で担当が分かれ、各々の担当範囲で各担当が責任をもって開発する形態も多いと思います（自分はそれしか知らないだけですが）。そのような場合、SVNかGitの二択で言えば、SVNのほうが向いている気もします。逆に、その状況ではGitの分散管理の仕組みは煩雑になりそうです。

OSS開発であればGitの一択でしょう。そもそもOSSのリポジトリとしてはGitHubが標準的に使用されている印象ですし（Issueなどの管理についても）、GitHubだと新しく参加する人も含めて世界中から多数の開発者が同一コードをレビューできますし、それに、予め「このライブラリの担当者はあなた」のような分担の仕方もしません。GitというよりはGitHubですが。

ですので、整理の要点としては、もしSVNかGitかのどちらを導入するのが良いのかを決めるとすれば、現在開発に参画しているエンジニアのスキル、プロジェクトの体制、それらを考慮して決める感じでしょうか。Gitを使いたいのならGit一択ですし、メンバーがGitに習熟していなければ学習時間を確保する必要もあります。

SVNの仕組み・コマンドはシンプルだし、それに必要もなくわざわざGitに鞍替えすると貴重なリソースである時間を食うだけになるかもしれません。一概にGitが良いとは断言はできないでしょう。そもそも仕組みが違いますし、VCSの導入目的は「ソースコードのバージョン管理」であって「Gitを使うこと自体」が目的だとそれは手段の目的化です。慣れないツールを導入して混乱を招き時間を消費する…というリスクも考慮すべきです。でも、メンバーがGitに慣れているならGitが第一の選択肢でしょう。

ツール以外の要因を考慮することも大事だと思いますので、単純にどちらが良い・悪いは言えなさそうです。アーキテクチャーの違い、エンジニアのスキル、習得のための時間確保などを勘案し判断する……という視点で考えたほうが良いかもしれません。

参考資料