Vol.54(2009年12月24日発売)今回のゲストは、分散バージョン管理システムGitのメンテナで『入門Git』(⁠注1)の著者、濱野純さんです。Torvaldsさんから引き継いでGitのメンテナになった経緯から、対談スタートです。弾:Gitに関わったきっかけは?濱:2005年の4月にLinuxカーネルのバージョン管理システムとして使われていたBitKeeperが使えなくなる[2]からということで、Linus君がいろいろありものを探したんだけど、使えるものがなくて、誰かがいいのを作ってくれるまでのつなぎというつもりで、とりあえず自分でもコードを書いた、というアナウンスをしました。それをカーネルメーリングリスト(ML)で見ていたんですが、たまたまボクの本業がプロジェクトとプロジェクトの合間だったんです。なんかおもしろそうなこと始まってるじゃん、ということで、彼が書いたコードをダウンロードしてみたら、1,244行しかなくて。弾:全部Cですか?濱:そうですね。そのくらいだったら、2時間で読めるでしょ。隅から隅まで読んでみると、すごくきれいに書けてるので感心して。ボクは基本的にカーネルの開発者でもなんでもなくて、カーネルMLもちょっと眺めてただけっていう感じでした。何十万行もあるカーネルのソースに関わるのはたいへんかもしれないけど、1,200行くらいから始まるこのプロジェクトなら今から入ってもおもしろいことができるかな、っていうのがGitに関わった動機の1つ。当時、1週間くらいの間にいろんなことが起こったんですけど、Linuxのカーネル開発者はLinusがわけのわからないものを使うと言ってるから、俺たちも使わせられるんだろう、あんまりひどいものを使わせられたんじゃかなわないって言うんで、力を貸して良くしようとしていました。本当に必要なものは何かと考えてみると、とりあえずコミットはできるようになって、前の版からの差分も見られるようになった。マージがなかったんです。Linus君がもともとマージはこんな形でやりたいというアウトラインを何回かポストしていたんですが。弾:Linusが一番文句付けてたところですよね、既存のバージョン管理システムで。濱:彼はCとシェルでしか書かないものですから、このマージのロジックくらいになるとさすがにかなり複雑だからスクリプト言語かなんかで誰かさらっと書いてくれたほうがいいんだけどな、みたいなことを、何回もMLに投げてたんです。誰も食いつかなかったんですよ。それで1週間くらい、ずーっとMLを見て勉強して、Linus君がやろうとしているマージのアルゴリズムをちょっとPerlで書いてみたっていうのを投稿した。それがボクの一番初めのある程度の規模のコントリビューションです。そのときに丁寧にテストケースを、こういうときにはこうって場合分けのテーブルを30個くらい書いたんですけど、それから6時間くらいして、Linus君が自分のツリーにコミットしたマージのやり方は全然違うものだったんですよ。すごい別のやり方考えたから、これで行くよって。見ると確かにコロンブスの卵で、ボクは今までMLでこんな形でやるよってLinus君が説明していたのに従って、丁寧にコードを書いたわけだけど、確かにそれを全部捨ててしまうくらいすっきりした、おもしろいやり方だったんです。誰かやってくれないかって言うからやってあげたのにってカチンときそうなものなんだけど(笑⁠)⁠、そのときに全然そうではなかったのは、もちろんボクが聖人君子だからじゃなくて、それだけすごいものがあったんです。[2]開発元のBitMover社がオープンソースプロジェクトに対して許していた無料使用のライセンス供与を取り止めたため。弾:どうコロンブスの卵だったんですか?濱:ボクはBitKeeper使ったことないんですけど、BitKeeperのやり方は基本的にワークツリーに自分のファイルがあるとすると、その中ではマージしないそうなんです。テンポラリディレクトリみたいなものを作って、そこにマージした結果を開いて、コンフリクトがあるものはそっちで解消して、その結果をコミットしたものが自分が普段使っているワークツリーに開かれて、それでマージ完了になる。いう形だったらしくて、もともとそれを踏襲したような形にするつもりだったらしいんだけど、結局そうしても最後にマージコンフリクトを解消した結果を、実際にコミットしてしまう前に、一度テストしたいよね。するとワークツリーの中で直接、テンポラリディレクトリを使わずにマージできたほうがいいよね、っていうことになって...。Gitでコミットする前に、次のコミットに入れるファイルの内容を登録しておくインデックスがあるんですけど、そのインデックスは当初、1対1だったのをやめにして、ステージという概念を導入すると言い出したんです。いうことかというと、もともと3ウェイマージをするものだから、最初のバージョンから私はこんな変更をしました。あなたはこんな変更をしました。いう差分を持ってきてマージする。この3つをステージ1、2、3っていうふうにインデックスに登録して、それでマージすればいいじゃん、とLinus君がいきなり言いだしたんです。確かにそうするといろいろおもしろいことができる。単純な例としては、私もあなたも何もしなかった場合。したら結果はもとのまま。それから私は何かしたけど、あなたは何もしなかった場合。したら私の結果をとればいいし、その反対も同様です。1つおもしろいと思ったのが、実は私もあなたも同じことをしたっていうケースなんです。弾:結構あります(笑⁠)⁠。濱:使ってみると実は確かにそうなんだけど、特にLinuxカーネルのプロジェクトは、MLベースでしょ。同じパッチを見て、これはうちのサブシステムもフィックスだからって拾った、だけど、実は別の人も拾ってたとかいうことがある。いう場合分けというのはインデックスの中で全部できてしまうので、効率もいいし、非常に見通しがいい。濱:それと彼は、よくメンテナの仕事の半分はNoって言うことだっていう言い方をするんですけど、人のパッチを捨てるっていうときにも、パッチというか、この変更はペケなんだけど、でもそれはお前がペケなんじゃないよって、すごく人を大事にした捨て方をするんですよね。それがすごいなと思って。ボクのときも、コードは捨てるけど、君のテストケースはそのまま使えるはずだから、こういう形でマージを作ってみたんだけど、やってみてって言われて。濱:人がしたことを無駄にしてないんだよというのを相手に知らしめると、コントリビュータのモチベーションを下げないで済むんですよね。新しいマージのやり方っていう発想もすごかったんだけど、コミュニティマネージャとして、人を使うマネージャとしての資質もすごい人だなと。それではまっちゃいましたね(笑⁠)⁠。GitHub弾:GitHub[3]ってありますよね。あれはGitと組織的なつながりはあるんですか?Gitコミュニティがエンドース(支持、承認)してやってるのではなくて、Git好きの人がやってる?濱:あれはちょっと複雑な立場なんです。GitHubを始めた人たちは、Gitコミュニティの人が知らなかったような人たち。あの人たちって基本的にRubyの人ですよね。RubyコミュニティでGitを使っていたのはRailsがGitを採用したとかの流れがあったんだろうけども、GitHubは最初、あれだけ流行る前にインビテーションベースでテスト運用をしていたらしいんですが、そのときにもGitコミュニティの主要メンバーに誰にもインビテーションが来なかった。ボクはあんまり気にしないんだけど、中にはそれでコマーシャルベースにのせてなんかやってるっていうのでカチンときた人もいたみたいで、結構長いことあんまり仲良くなかったんです。弾:そうだったんだ、GitとGitHub(笑⁠)⁠。相手のことを見てなくて。濱:見ないで走ってたというところがあって、たとえばもともとのGitとGitHubが動かしているGitデーモンとではちょっとバージョンが違うのかな。手を入れてなんかやってるとか。隠れたところで非公式なものを作られると困るから。弾:それは大いに困りますね。togetherっていうイベントがありまして、Googleが場所を提供してくれて、3日くらいやったんですけど、そのときGitHubの人たちもGitコミュニティの主要メンバーということでやってきて、これからどんなふうにしていこうかねって話をしたりして、今はそんなに悪い感じではなくなってます。実際、GitHubのヘルプコンテンツとかって結構いいでしょ。やって、ドキュメンテーションとかユーザサポートとか、自分たちの得意分野でやってくれる人たちがいるんだったらいいことじゃない。弾:何の過去もない人たちがいきなりGitHubから始められるわけですよね。確かにあれは世界が変わると思いますよ。最初から世界に向けてソースコードを単に公開するんではなくて...。濱:みんなでなんかやっている、マージし合っているという、あの構造はすごくいいですね。ままずーっときてたと思います。濱:あれは非常に斬新だった。細かいところで注文はつけたい部分はあるけれど、GitHubがGitの普及に果たした功績ってすごく大きかったですね。弾:あれを見てやっと、なんでLinusが今までのバージョン管理システムにケチを付けているのかも実感できた。マージできねえじゃんと。結局、Linuxカーネルほどばかでかいプロジェクトだと確かに、どっちのコードを入れてどっちを捨てるというのも大問題になるけど、普通は入れるか入れないかですし、メンテナは各プロジェクトで1人で済んでいて、1人では間に合わなくなったらプロジェクトをサブプロジェクトに分割してっていうやり方を今までしてきて、それでほとんどのものは間に合ってきたじゃないですか。確かにありがたみがわかりませんよね。GitHubだと使っている人たちが、こりゃあちょっとマージしないとやばいよなというのは嫌でもわかるようになりますよね。あれはすばらしいですよ。Railsで作られたGitのプロジェクトホスティングサービス。弾:「優れたエンジニア」とはどんな人だと思いますか?濱:Gitのメンテナを引き継ぐときにLinus君に、スターエンジニアには3つの資質があるって言われたんです。重要なのは、何か1つのことをずっと続けていけること。いう意味ではアルファギークではいけないわけ。尖鋭(せんえい)的で、新しいものにすぐ飛びつく、までは構わないけど、すぐ飽きちゃダメ。ちなみにボクは尖鋭的でも新しもの好きでも飽きっぽくもないので、およそアルファギークではありません。