git利用者に贈る、Subversionがダメな理由

このブログを始めてからだいたい２年が経ちました。
２年前はどんな記事を書いてみたのかと見てみると……

これですね。
このときはプログラミング始めたてで、まずは git の使い方を覚えようとしていたようです。

このように、ここ数年でプログラミングを始めるようになった方は git からスタートしていて、
逆に Subversion ( SVN )を触ったことがない方も多いのではないかと思います。

では、なぜ現在は Subversion でなく git が使われるようになったのでしょう？
数年前、あるプロジェクトに参加したとき Subversion を初めて使ったところ、
「これはたしかに使いづらい……」とわかり、git が広まった理由を感じられましたので、
git に慣れた者にとって Subversion がつらかったところについてまとめたいと思います。

1. コマンドが長い！

1-1. init

ます、バージョン管理のためのディレクトリを作成する init コマンドを比較してみましょう。
すでにプロジェクトフォルダーへ移動しているものとします。
また、今回は Windows PowerShell 上での実行を想定しています。

gitの場合：

git init

svnの場合：

# まずはローカルもしくはサーバー上に、バージョン管理に使うディレクトリを用意します
# git init との比較ですから、今回はローカル環境に管理ディレクトリを作成することにします
mkdir /svn_repos/project_name
svnadmin create /svn_repos/project_name
svn mkdir file:///svn_repos/project_name/trunk file:///svn_repos/project_name/branches  file:///svn_repos/project_name/tags -m "created default directories: trunk, branches, tags"

# バージョン管理に使うディレクトリを作りましたので、それを pull します
# svn では、git pull は svn checkout です
# "まだプロジェクトフォルダー内に何もデータがない場合"は、以下の１行で済みます
svn co file:///svn_repos/project_name/trunk

なお、Windows10 の PowerShell でおこなっていますので、
もしかすると以前のOSですと /svn_repos や file:///svn_repos といった省略型が認識できないかもしれません。
その場合は、 c:/svn_repos や file://localhost/c:/svn_repos に、それぞれ置き換えてください。

また、プロジェクトフォルダー内にデータがある場合は、
チェックアウトする前にプロジェクトフォルダーを一度コピーして隔離しておく必要があります。
こちらをご覧ください : svnコマンドでリポジトリ作成する手順 – 打つか投げるか

1-2. commit

コミットするときのコマンドを比較してみましょう。
ここはほとんど同じですが、基本の流れですので書いておきます。

gitの場合：

ni test.txt # ni : New-Item を意味する、PowerShell 独自のコマンド。bash での touch コマンドに相当
git add .
git commit -m "created a test file"

svnの場合：

# 先ほどチェックアウトしたことでプロジェクトフォルダー内に
# trunk フォルダーができました。データはそのフォルダー内に置いていきます
cd trunk
ni test.txt
svn add *
svn commit -m "created a test file"

1-3. branch

ブランチを作るときのコマンドを比較してみましょう。

なお、Subversionにおいてブランチを作るというのは、
trunk フォルダーのコピーを指定ディレクトリに作る作業です。
したがって、ブランチを作れば作るほど、どんどんバージョン管理ディレクトリ以下の容量は増えていきます。

また、タグもブランチと同様です。
言ってしまえば Subversion にタグやブランチの機能なんてものは無く、
ユーザーが『慣例的な使い方をする』ことで成り立っています。

詳しくはこちら : 今更聞けないSubversionの使い方

Subversion から git へ移行したくてもできない人が語る、
「SVNリポジトリの容量がやたらでかくて……」というお話は、こういうところに由来します。
（その他に以下で述べる、ignore がしづらいため無駄なファイルが……、などの理由も加わるでしょう）

gitの場合：

# 方法1 : ブランチを作りつつそのブランチへ移動
git checkout -b new_branch_name

# 方法2 : 上記コマンドが一般的かと思いますが、いちおう素直にやるのなら、
# 以下のように、ブランチを作ってから移動
git branch new_branch_name
git checkout new_branch_name

svnの場合：

svn copy file:///svn_repos/project_name/trunk file:///svn_repos/project_name/branches/new_branch_name -m "create new branch"

このように、ブランチやタグを作る際にも、管理フォルダーへのURLが必要になります。
今回の例のようにローカル環境に管理フォルダーがある場合はまだいいのですが、
これが社内サーバーだったりすると、いちいちURLを探してコピペしてくるのが面倒だったりします。

git remote set-url コマンドのありがたさを理解しました。

2. ローカルコミットができない

先ほど書いたコミット、ほとんど同じと書きましたが、中身は異なります。
git は commit してリモートリポジトリに push するという流れが一般的です。
一方 Subversion では、commit コマンドの段階で、checkout 時に用いたURLへの送信がおこなわれます。

つまり、Subversion の commit は、git の commit と push が一度におこなわれることを指します。
svn push というコマンドは存在しません。

一見、問題ないかに思えますが、チームでおこなうプロジェクトではなかなか困ったことになります。
書いているコマンドが常に完璧なわけではないですが、ロールバックを考えると、
なるべく頻繁にコミットすべきと git 利用者は考えます。
しかし Subversion では、コミットした途端にリモートリポジトリへの同期がおこなわれてしまいます。
当然、これではコンフリクトの機会も多くなり、コミットできない……コンフリクト解消しなきゃ……の作業を繰り返すことになります。

それから、ブランチを作る際も、git と違いローカルにバンバン作れません。
（仕組みを考えると、個人がローカルにブランチを作ることが可能なのですが、面倒なのでたいていリモートリポジトリにそのまま作っているかと思います）
git co -b を打つことがたびたびある git 利用者にとっては、なかなかつらさがあります。

以前Twitterで『ブランチを作るのに申請書が必要』とブラック会社談義を見てどういうことかわからないでいましたが、
Subversion でならたしかに各人がバンバン作ると混沌化しますので、その規則が生まれるのもわからなくもないです。

3. ignore しづらい

.gitignore ファイルを作るのとはわけが違います。
これは説明が面倒ですので、Subversion での ignore の設定法は以下の２つの記事をお読みください。

Subversion/svn propset/ignoreの除外リストをファイルで管理 - yanor.net/wiki
SVNで特定のディレクトリ以下の更新を無視する - ふなWiki

設定が複雑なので、ignore の設定が正確におこなわれずに不要なファイルがコミットされてしまうことはよくあります。

4. コードレビューしづらい

GitHub もねぇ、BitBucket もねぇ、GitLab だってあるわけねぇ！ の世界です。
調べたら、 CodeBarg というものがあるようですので、
もし会社が Subversion 環境だけどGitHub的コードレビューの慣習を入れたい、という場合は、
これの提案をおこなってみるといいかもしれません。
Codebrag·Subversion/Git対応のコードレビューシステム MOONGIFT

私が参加していたそのプロジェクトではコードレビューは存在しませんでした。
イサギイイネ・・・

5. コマンドだと大変なので結局GUIツールを使わざるを得ない

最初に書きました 1. の理由もあってか、たいていの人は TurtoiseSVN に落ち着きます。
TurtoiseSVN なら、ブランチ・タグの作成やコンフリクトの解消などが、わりとカンタンにおこなえるためです。

バリバリとコマンド入力をおこなうプログラマーの方にとっては、
GUIツールでバージョン管理をしていることで、体が腐っていく感覚が味わえるかもしれません……。

最後に

というわけで、git利用者が Subversion を使ってみたときのつらみについて書いてみました。
Subversion が必ずしも使いにくいかというと、Visual Studio を使っている人にとっては、TurtoiseSVN が統合されているために Subversion の方が手軽だったりする場合もあるようです。

しかし最近の Visual Studio、特に Visual Studio 2015 以降では git もそこそこ手軽に扱えるようになったようですね。
（参考 : Visual Studio ローカルでバージョン管理(git))

Subversion を使っているところには早く git に移行してほしいなと思うしだいです……。