私は業務でのバージョン管理ではSubversionしか使ったことがありません（こっそりローカルでGitを使ったことはあるけど）
多くのOSSがGitで管理され、GitHubで公開されるようになっているのも最早「最近」とは言えないようになってきている今日、なんとかGitを導入したい、させたい。という方の一助となればと思い、メモしておきます。
既にGItが主流になっている
冒頭でも触れましたが、既に多くのOSSはもうGitでバージョン管理されています。
Googleトレンドでバージョン管理ソフトの検索件数も、2012年には逆転されています。
現在の状況はこちらから見てみてください。
何が違うのか
Subversionは集中型、Gitは分散型のバージョン管理システムと呼ばれています。
Subversionでは「レポジトリ」をチェックアウトしてきた「作業コピー」上でファイルに変更を加え、その内容をレポジトリへコミットします。
一方でGitは、作業者全てが「レポジトリ」を持っている形になります。GitHubなどで管理しているレポジトリは「これがアップストリーム」と決めているだけで、レポジトリの1つに過ぎません。
分散型の場合は、ひとつのレポジトリの中でバージョン管理が完結しているということになります。
※それによる恩恵は後述。
いいこと
コミットを溜められる
「新規機能は単体テスト終わってからコミットしてね」と言われたとします。絶望しか無い。実際にコードを書いていると、もっと細かい単位で状態を保存しておきたいと感じるかと思います。色々面倒な設定を乗り越えてDBからデータを取得できるようになった時、できるかわからないけど試してみたい修正がある時 etc...
そんな時にGitはコミットしてもプッシュするまでは、状態をローカルのみに保持しています（SVNのコミットがGitのプッシュに相当している）。気軽にゲームのセーブデータが作成できるようなものです。詳細は割愛しますが、完成したらコミットをまとめてpushすることもできます。
ローカルブランチを切れる
前述の溜めた"汚い"コミットの状態は誰も使いませんが、差分やログだけ参照したいものです。説明の順番が前後しましたが、開発時にはmaster（SVNのtrunkに相当）からブランチを切って、masterは常に"綺麗な"状態に保つことができます。
オフラインで作業ができる
今日ではあまり有り難みがないかもしれませんが、レポジトリの情報全てを保持しているためpush（SVNのcommit）とpull（SVNのupdate）以外の作業はほとんど可能です。個人のローカルだけで何かをバージョン管理したい場合でも、簡単にできるということになります（SVNでもローカルでサーバー立てて云々とできることにはできますが）。
ログの確認も、特定のリビジョンにおけるファイルの内容もできます。
悪いこと
学習コストが高い
Subversionで多くのユーザーが使っているであろうTortoiseSVNでは、用語さえわかっていれば右クリックひとつでなんとなく把握出来てしまうくらいに、使いやすくシンプルです。
一方でGitはできることが多いために、覚えるために少し、ほんの少し時間がかかる場合もなきにしもあらずです。
部分チェックアウト・更新ができない
できないのです（厳密にはできなくないが、面倒）。
しかし、更新漏れが無くなる＝レポジトリ内の不整合がなくなる。というメリットでもあります。
部分チェックアウトが本当に必要か、考えなおしてみましょう。
リビジョンが番号じゃない
Gitのリビジョンはハッシュです。（例：7c5b61696a13550b7a8592324cc9368622990007）
リビジョン番号だけで内容が分かる変態同士の会話でない以上は、ログを参照しながら会話することになるのでそこまで大きなデメリットではありませんが、少しだけ面倒です。
余談ですが、仕組み上コミットは頭4桁だけでほぼ一意に定まるそうです。
まとめ
以上、簡単にSubversionと比較してGit導入のメリット・デメリットを紹介しました。
記事の長さのバランスのために割愛しましたが、まだまだ沢山できること・小ネタもあります。
もし本記事で興味を持ってくださった方いらっしゃいましたら、使ってみてください。とても楽しいです。そしてGitユーザーが増えたらいいな、と思います。