DVCSを使っている方の話を聞くと、まだ全社的にSubversionからGitに切り替えるだけのメリットが見えないな～という思いがありました。そこで、本格導入した他社がどうしているのか気になり、参加してきました。
イベントのURLはこちら。
大盛況でかなりの席が埋まっていました。やっぱ、みんな気になってるんですかね。
流れとしては登壇者ごとに発表し、そのあとにディスカッションとなりました。以下、そのレポートです（半分書き起こしになってしまいましたが…）。
～第一部 プレゼンテーション～
1. グリー株式会社 大場さん『本当のレガシーの話をしよう』
◆SCMの歴史について
以下、時系列に並べます。
[SCCS]
SCMの歴史はSCCSから始まった。
1972年ベル研究所で誕生。
ここでバージョン管理という概念が生まれた。
[RCS]
SCCSのコマンド体系をベースにGNUフリーで公開。
ロックベースだったので管理が難しい。
⇒会社でロックしたまま帰っちゃう人がいて困ったり。
⇒OSS開発のように地理的に離れているとなおさら辛い。
[CVS]
マージという概念を生み出した。
ロックの制約がなくなり、時間や場所を超えた開発プロジェクトが可能となった。
多様な環境で動作するアーキテクチャとなっていたことが魅力。
移植がしやすかった。
[Git]
分散リポジトリに対応。
ブランチを使った並行開発が実用的になった。
◆GREEのSCMの遷移について
最初は社長が分散を管理（笑）。
手作業で更新を管理していた。
その後、Subversion、Git、GitHubへと移行していった。
◆ブランチ管理
ブランチの管理にはgitdailyを利用している。
⇒Gitのブランチ管理があまりに自由すぎたため導入。
2. 株式会社ドリコム 大仲さん『マジカルSVNとキュアGit』
◆理想と現実
理想の開発フローはpull requestとチケット駆動の組み合わせ。
でも、SVNだとマージがアホだし、ブランチを作るのも大変。何より、重い。
それを解決してくれたのがGit。
一度githubでリポジトリブラウザを使い、その速さを実感してみるべき。
◆Git導入によるメリット
Gitにしたことによって、マージするときに必ずコードを見るようになった。
⇒つまり、自然とコードレビューが行われるようになった。
◆Webでの管理
フロントエンドの要件として考えているのがWeb UI。
管理もWebでしたい。
◆SubversionからGitへの移行
新規はGitから始めるので問題ない。
問題は数年続いてきたような過去のプロジェクト。
そのようなプロジェクトに対してはSubversionとのクロスコミットで対応した。
ただ、これまで築き上げたワークフローは壊したくなかったので、開発はGitで、
リリースはSubversionで、というように使い分けも行った。
◆Git導入に向けた社内への説得
上（上司）と横（同僚）には異なるアプローチで対応。
上が気にするのはイニシャルコスト。
なので、いきなりgithub:enterpriseを使いたいとは言えない。。
そこで、まずはgitlabから始めることでこの問題をクリア。
横に対しては変更履歴管理のメリットを伝えた。画像を比較できるとか。
移行しない理由を一つずつ潰した。
⇒推奨クライアントを決めたり、設定をドキュメント化したり。
IRCをチェックし、プロジェクトで湧きあがった不満には即対応。
各プロジェクトに経験者を配置し、トラブルに即対応できる体制を作った。
移行しないと！と思わせるような空気も大事。
web UIだとSubversionとのギャップを感じずに済む。
3. クルーズ株式会社 梅田さん『Gitと出会って人生変わった』
◆Git導入以前
Git導入以前はtrunkのみで運用していた。
さらに開発用とリリース用のリポジトリを分けて運用しており、
リポジトリ間の同期は手作業で管理。。
この状況を改善すべく、Gitを導入した。
◆Git導入後
Gitだとマージやクローンが早くて楽！
デプロイツールにはCapistranoを使っている。
これを使うことで、リビジョン指定ができたり、ロールバックが可能になった。
◆Gitを導入するために
はやりを使うのは楽しい！というのがモチベーションとなった。
新しいことをしようとすると（偉い人とかに）色々言われてめんどい。
なので、まずは勝手に始めて、動くところを偉い人に見せるのもあり。
4. 株式会社モバイルファクトリー 阿部さん『Git移行の3つの山』
動機、実行、その後。この3つが大切。
◆動機
当初はSubversionで十分では？との意見があった。
社内で分散型の管理が本当に必要か？など。
ただ、最後に「速さ」が導入の決め手となった。
◆実行
中心となる方が1人いて、推進していった。
やはりこうして中心となって進めていく方がいないと進まない。
◆その後（アフターケア）
一気に切り替えたので当初はばたばた。
IRCでサポートを行ったりした。
5. KLab株式会社 於保さん＆牧内さん『メタにGithubを使う』
◆SCMの遷移
KLabでもコード管理はSubversionから始まった。
↓
Subversionに近いDVCSとしてBazaar導入。
↓
リポジトリの整理とGithubを使いたいという声が上がり、Githubを導入。
◆課題とそれに対する対処
エンジニアリングマネージャという立場上、レビュー依頼が多い。
でも、リポジトリが増えすぎて現実的には無理。。
なのでpull requestを監視し、アンチパターンを検出するようにした。
このパターン定義は正規表現で行っている。
検出したものはデータベースに蓄積し、まとめて表示できるようにした。
～第二部 パネルディスカッション～
◆Gitを導入するメリットは何か？
・ソーシャルコーディングという文化を取り入れられること。
・速さが嬉しい。
1行コミットするのに待たされたくない。
ブランチ作成が早いのは嬉しい。
・Subversionだとコミッタが特別な存在だったが、Gitだとその敷居が少し下がった。
◆リポジトリを分散するメリットは？
・ローカルで管理できる。そのため、スピードが速くなった。
・個人で開発する時、ネットワークのない環境でも管理できるのが嬉しい。
・ブランチを気楽に作り、うまくいかなければ丸ごと消せるのは楽。
◆Git移行の壁
・Gitで抵抗が多いのはバージョンの概念が変わったことでは？
・バージョンをSubversionのように数字で見れないのは辛い（という声が社内にあった）。
・Subversion向けに開発されたツール資産を捨てられない。
・GitだとWindowsのクライアントで良いのが無い。
◆壁の乗り越え方
・新しいことを覚えたくないという抵抗勢力は首にしてしまえ！
・デザイナーのようなGitに慣れていないユーザにはGUIツールを使ってもらう。
・とりあえずやってしまう。
・CTOからドカンと言ってもらう。
・移行しないと、という空気を作る。
・グリーの場合は履歴を捨てて、一気に移行した。ただデプロイ手順とかは過去と同じようにできるようにしたりと、捨てるもの、引き継ぐものをわけた。
・チームに経験者が2人は必要。でないと初心者対応の負荷が集中してしまうから。
・新しい文化を恐れない
◆git-svnについて
[グリーの場合]
git-svnはSubversionに合わせたツールなので、gitらしい管理がしづらい。
そのため、git-svnを使うのではなく、プロジェクト単位で分けて管理していた。
[ドリコムの場合]
git-svnを導入した。
もし、コンフリクトが発生した場合は手動マージする覚悟でいた。
[KLabの場合]
git-svnで移行を進めた。
◆gitのコマンドについて
gitのコマンド体系はアーキテクチャと密接に関係している。なので単なるツールとして使おうとすると辛い。ワークフローも含めて見直しが必要になる。
最低限必要なコマンドは3,4つくらい。それさえ覚えればいいのだから、簡単です！（by 大場さん）
Twitter上や名刺交換の場でお話を伺ったことについては別記事にまとめる予定です。
[2013/03/24追記]
第5回テックヒルズ『Go to Git !』～さらばSVN～ 番外編 アップしました！
