昨日の『第5回テックヒルズ『Go to Git !』～さらばSVN～ レポート』
http://taityo-diary.hatenablog.jp/entry/2013/03/23/154425
の続きで後日談というか、番外編というか、Twitterや直接お話を伺ったことをまとめます。直接お話を伺ったことも基本的にはtweetしているので、それをまとめる形にします。
◆ブランチの使いどころ
@jo7ueb ブランチはどんな場面で活用しますか？
— ぱと (@pato_taityo) 2013年3月22日
@pato_taityo 機能追加とかは間違いなくブランチ切ります．失敗して偉いことになったとしても，えいやっと戻ることができて心理的な障壁が下がると思います．あと，特定の作業に関するコードを集中させられるってのも美味しいと思います．
— Neppo Telewisteria (@jo7ueb) 2013年3月22日
コメントいただいた内容と同様のことをディスカッションでも聞きました。
Subversionだと機能追加程度でブランチを作るのは遅いし大げさな気がする…とちょっと尻込みするところがあります。Gitだと早いしローカルでやればいいし、と敷居が下がりそうです。
◆ブランチの管理について
Gitによってブランチを使った並行開発が実用的になったという話だけど、ローカルブランチを他の人が参照できない問題はどうなんだろう？また、ブランチ間の管理はどうしているんだろう。 #techhills
— ぱと (@pato_taityo) 2013年3月22日
.@koichiroo さんに伺った話。ローカルで管理しているブランチをマージする前に誰かへ見せたりしたいときにどうしてますか？と聞いたところ、pull requestのコメントの先頭に『マージしないで！』と書くという運用でカバーしているとのこと。 #techhills
— ぱと (@pato_taityo) 2013年3月23日
ブランチは自由なようで不自由な面もあり、そこはツールや運用でカバーしていくことになりそうです。
◆Gitの速さはどんな場面でメリットになる？
Gitにすることで速いのが嬉しいのは何と無く分かるけど、どんなシーンで嬉しいのだろう？そこまで嬉しくなるシーンがあまり具体的に浮かばない。。 #techhills
— ぱと (@pato_taityo) 2013年3月22日
@pato_taityo ブランチがまともに動くのはすごくおいしいです
— Neppo Telewisteria (@jo7ueb) 2013年3月22日
@pato_taityo すべての事柄がちょっとずつ速いことにも意味があります。3G 回線と wifi の違いみたいな。 #techhills
— Takafumi ONAKA (@onk) 2013年3月22日
ドリコムの大仲さんに伺った話。Gitの速さはブランチやマージでいきてくる。リリースサイクルの速い開発をしている時はブランチで待たされることすら辛い。それに普段でも短いコードをコミットしたいだけなのに待たされるのは嫌ですよね？ #techhills
— ぱと (@pato_taityo) 2013年3月22日
Gitの速さについては発表やディスカッションでも繰り返し強調されていました。この速さがGitの文化を支えているように思えます。
◆metahubのパターン定義
アンチパターンは正規表現で定義しているのか！複雑なものは辛くないのかな。。 #techhills
— ぱと (@pato_taityo) 2013年3月22日
KLab 牧内さんに伺った話。正規表現でのチェックはあくまで取っ掛かり。なので、誤検知も多い。それでもきっかけになるのは大きい。あと、当然ながら個々の案件でもコードレビューを実施しており、クラス設計といった内容はそこのレビューでチェックされる。 #techhills
— ぱと (@pato_taityo) 2013年3月22日
metahubはあくまでプロジェクトを横断的にレビューする必要がある方向けのツールとのことでした。誤検知は多いけど、それでも事前にパターンが頭に浮かんでいる状態でレビューできるのは楽です、とのことです。
◆マージの賢さ
Gitだとマージが賢いというけど、そんなにSVNと違うのか？SVNだと実現できないのはなぜだろう。アーキテクチャレベルの問題？ #techhills
— ぱと (@pato_taityo) 2013年3月22日
@pato_taityo SVNだとブランチを切った際に親の情報が失われやすく、Gitの標準マージ戦略であることの3-wayマージがしづらいという話を聞いたことがあるのですが、そもそも私はSVNのことをよく知らないので、ぜひ誰か詳しい人の解説が欲しいですね #techhills
— でこくん (@dekokun) 2013年3月22日
@pato_taityo 3-way merge なので。 #techhills
— Takafumi ONAKA (@onk) 2013年3月22日
3-way mergeについまとめたエントリがあったのでご紹介。
http://forza.cocolog-nifty.com/blog/2012/06/3-a4c2.html
コメントいただいたように、
Subversion：ブランチの派生元情報を失う
Git：ブランチの派生元情報を保持する
という違いが2-way/3-way mergeとなり、マージの優劣を決めているようです。
3-way mergeについては入門Gitの2.8.1(P23)にも解説があります。
- 作者: 濱野純(Junio C Hamano)
- 出版社/メーカー: 秀和システム
- 発売日: 2009/09/24
- メディア: 単行本
- 購入: 31人 クリック: 736回
- この商品を含むブログ (155件) を見る
マージ優劣の差は使い勝手としても大きいらしく、ディスカッションでも話題にのぼっていました。
◆SubversionとGitのクロスコミット
SVNとGitのクロスコミットで困ったことは無いのだろうか？ #techhills
— ぱと (@pato_taityo) 2013年3月22日
@pato_taityo 何かあっても diff とってコミットしたり、git 上で reset HEAD~1 等でなんとかするつもりで導入しました。移行してから svn のリビジョン 2 万ぐらい増えましたが、今のところ直接 git プロジェクトは一度も弄んなくて大丈夫でした。
— Takafumi ONAKA (@onk) 2013年3月22日
とのことなので、当初はSubversionと共存して徐々にGitへ移行する、というのも現実的な選択肢のようです。
◇総括
全体を振り返ると、SubversionからGitへの移行において、技術面での課題はあまりなさそうです。それよりも、文化を変える覚悟があるかという点が問われているように思います。
文化を変えるということは技術面での問題をクリアするより時に難しいことになります。それを変えていくには強い思いを持ったリーダーが必要となりそうです（実際、今回のお話を聞いていても、そういう存在が引っ張っていった印象がありました）。
ただ、たとえ自分がリーダーにはなれなくとも、サポーターにはなれるはず。その時に備え、まずはGitに触れてみることから始めてはいかがでしょうか。
