SubversionからGitへの移行をオススメする７つの理由

git svn

1. Subversionと連携できる

Subversionのtrunkだけでなくbranches, tagsもちゃんとローカルのGitリポジトリへ同期できます。
http://sourceforge.jp/magazine/09/03/26/0834222

実際僕はいくつものプロジェクトで、チームのリポジトリがSubversionであっても、自分の開発PCではGitを使ってSubversionと同期して開発してきました。これからもそうしていきます。

2. Subversionの履歴を引き継げる

Subversionと同期できるようにローカルにGitリポジトリを作ると、そのSubversionの履歴もGitリポジトリに引き継がれます。ですのでSubversionにある履歴がGitに移行したから失われることはありません。

3. Subversionからゆっくり移行できる

チームでSubversionを既に使っている場合、じっくり確実にチームが納得できる形で移行できます。

最初はみんなSVNに直接アクセスしてます。

         ------- [開発PC1]
         |
[SVN repo]  ---- [開発PC2]
         |
         ------- [開発PC3]


まずは試しに数人だけGitに移行します。まだチームとしてのメインリポジトリはSVNです。Git repoとSVNのSVN repoの同期は必要に応じて行います。

[Git repo] ------- [開発PC1]
         |
[SVN repo]  ---- [開発PC2]
         |
         ------- [開発PC3]


ちょっと使ってみてOKそうならメインのリポジトリをGitにするよと宣言して、みんなに移行を促します。まだ、Git repoとSVNのSVN repoの同期は必要に応じて行います。

         ------- [開発PC1]
         |
[Git repo] ------- [開発PC2]
         |
[SVN repo]  ---- [開発PC3]


地道にGitへの移行を進めていき、めでたく全員が移行するとSVN Repoとの同期が不要になります。

         ------- [開発PC1]
         |
[Git repo] ------- [開発PC2]
         |
         ------- [開発PC3]

4. Gitは速い

僕は開発をしていて普段ほとんどgitを使っているので、当たり前になりつつありますが、通常のadd, commit、pull/pushがストレスなく動くのでたまにsvn使うたびにGitへの移行をオススメしたくなります。

5. チームへのコミットと自分自身の作業の区切りが分かれる

svnの場合、コミットはチームの他のメンバーへ影響を与えることになりますが、gitの場合はコミットの時点ではローカルのリポジトリにコミットするだけなので、メインのリポジトリへpushしない限り他のメンバーに影響を与えることはありません。

自動テストをチームで採用している場合、テストが通らないコードをコミットすることは、他のメンバーに余計な手間をかけることになるので、禁止されることが多いと思いますが、Gitの場合はコミットするタイミングとコミットをチームへ反映するタイミングを分けることができので、テストの通らないコードをローカルにコミットすることが許されます。これによって開発者は自分の作業の好きなリズムでコミットを行うことができるので、コミットを細かくすることが可能になり、コードの変更をトレースしやすくなります。

6. ブランチの作成／マージが楽

これは使ってみないと分からないと思いますが、SVNよりも遥かに楽だと思います。

7. Github

Railsアプリなどを開発しているのならプラグインを使うと思いますが、プラグインの多くはGithubで公開されています。
プラグインの多くはgithubで公開されているので、submoduleを使えば簡単にリンクさせることができます。

また通常SVNの場合、プラグインについてはsvn:externalsを使うか、プラグインのコードを通常のコードと同じようにコミットしてしまいます。
svn:externalsだと、プラグインのリポジトリでのコミットが意図せずプロジェクトに入ってしまう可能性がありますが、Gitのsubmoduleならそのリンク先のバージョンが固定されます。ですので、意図しないバージョンを使ってしまうことはありません。