gitの10周年を記念したLinus Torvalsへのインタビューの翻訳

10 Years of Git: An Interview with Git Creator Linus Torvalds | Linux.com

gitの10週年を記念して、リーナス・トーバルズがインタビューに答えている。以下はその翻訳である。


なぜGitを作ったのか？

トーバルズ‥俺はソース管理ツールなんて作りたくなかったし、コンピューターの業界において最も興味がないものだと見なしていた︵データベースは別だが︶。それにソース管理ツールなんてどれも嫌いだった。しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。BitKeeperは大抵のことを正しく行っていた。レポジトリのローカルコピーがあることと、分散マージはでかかった。分散ソース管理の何がいいかというと、ソース管理ツールの問題を吹っ飛ばせることだ。﹁誰が変更を行えるか﹂といった政治問題があるが、Bitkeeperは、全員に自前のソースレポジトリをもたせれば、そんな政治問題なんか消し去ることができるということを示してくれた。だた、BitKeeperにも問題はあった。一部の技術的な設計も問題︵リネームが辛かった︶だったが、最大の問題点は、オープンソースではないために、使いたがらない人間が多くいたということだ。BitKeeperはオープンソースプロジェクトには無料で使えたため、何人かのコアメンテナーはBitKeeperを使っていたものの、全員が使うには至らなかった。カーネル開発には役だったが、そういう頭の痛い問題はあった。

そこに、Tridge(Andrew Tridgell)が、︵それなりにシンプルな︶BitKeeperのプロトコルをリバースエンジニアリングし始めた。これはBitKeeperの利用規約に反するものであった。俺は数週間︵数カ月？　それぐらいはかかったように感じた︶、TridgeとLarry McVoyとの間を取り持っていたが、どうもうまくいきそうになかった。その時点で、俺はもうBitKeeperは使えないと判断した。とはいえ、俺はもうBitKeeper以前の時代に戻りたくはなかった。残念ながら当時、分散型のソース管理ツールはいくつかあったが、どれもうまくやっていなかった。当時存在したツールはどれも、俺の要求するパフォーマンスに全然追いついていないのだ。それに、コード品質や全体のワークフローのことも気にしていたので、自分で書くことにした。

どうやって書いたのか？　週末を徹夜して書いたのか、あるいは昼間だけ作業したのか。

トーバルズ‥いやｗｗｗ、gitのソースコードレポジトリの中に、実際に記録されているよ。最初の一日分はないがね。gitでgitのコミットをする、﹁セルフホスト﹂をするのに一日ほどかかったので、最初の一日かそこらは謎だ。だが、それ以外は全部残っている。作業は日中に行われたが、真夜中のコミットや、午前2時のコミットもいくつかある。すぐに形になったというのはとてもおもしろいことだ。gitツリーに対する最初のコミットは、そんなにコードがない。しかし、基本的なことはすでにやれていた。自分自身をコミットするには十分なほどに。問題はコード量ではなくて、どのようにデータを扱うかだった。

そういうわけで、10日間かそこらでモノにはなったものの︵その時点で、俺は最初のカーネルのコミットをgitで行った︶、素早くコードを書き散らしたというわけではないということは言っておきたい。初期の実際のコード量は、かなり少ない。基本的な考え方が正しいかどうかにかかっている。開発を始める前からそのアイディアについて考察していたわけだ。他のツールの問題は知っていた。何を避けるべきかも知っていた。

結果は期待通りであったか？　現在の状況は推定通りか？　なにか限界はあるか？

gitには満足している。カーネルに対して実によく動くし、いまだに期待通りの働きをしてくれる。俺にとって興味深かったのは、実に速く他の多くのプロジェクトを取り込んでいったかということだ。驚くほど早かった。ソース管理システムを変更するには様々な障害があるものだ。CVSやRCSが長年生き残っているのを見ても明らかだ。しかし、gitが取り込んでしまった。

なぜこんなにひろく受け入れられたと思うか？

トーバルズ‥俺がソース管理ツールを嫌っていた原因となる問題を、他の皆も感じていたのだろう。いくつかの些細な問題を解決しようと試みるプロジェクトはあったものの、根本的な問題に取り組むgitのようなものがなかったのだろう。﹁分散型﹂の部分の重要性を認識していない者でも︵結構な者が反対しているが︶、それにより簡単で信頼できるバックアップが可能になり、中央レポジトリに対する書き込みアクセス権などという政治問題に関わることなく、全員が自前のプライベートなテストレポジトリが持てると分れば、もう後戻りしたいと思うものなどいやしない。

Gitは一生続くのだろうか。あるいは、今後10年で別のリビジョン管理システムが現れるのだろうか。それを書くのはあなたか。

トーバルズ‥それを書くのは俺ではないよ。たぶん、10年以内になにか新しい物が出てくるだろう。だが、それはだいたいgitに似ているだろう。gitがすべてを正しく行っているためではない。gitは基本的な問題を正しく行っているのだ。既存の他のソース管理ツールがどれもできていなかったことだ。

自画自賛ではないよ^^;

なぜGitはLinuxに対してうまく動くのか。

トーバルズ‥そりゃあ、gitは我々のワークフローに対して設計されたからで、設計の一部だったのだ。すでに﹁分散型﹂の部分は何度も言ったが、何度も繰り返す価値があるものだ。また、Linuxのような大きめのプロジェクトに対しても十分に効率的であるように設計されている。そして、git以前ならば﹁難しい﹂と感じる作業を想定して設計されている。というのも、その作業は他ならぬこの俺が毎日行うことだからだ。

例えばだ。﹁マージ﹂という概念は、大抵のソース管理ツールではとても頭が痛くて難しい作業だ。マージのための計画を練る必要がある。とても重要だからだ。それは俺にとって許容できないことだ。なぜならば、俺はマージ期間中に一日あたり何十ものマージを普通に行うからだ。それも、マージ自体が面倒なのではなく、結果をテストすることのほうが難しくあるべきだ。gitでは、マージはたったの数秒のことだ、マージよりも、マージの説明メッセージを書く方に時間がかかるべきなのだ。

つまり、gitは基本的に俺の要求を満たすために設計されて、結果はご覧のとおりだ。

Gitは超絶天才な人間だけのものだと言う者がいる。Andrew Mortonでさえ、Gitは、﹁自分が思っているよりも頭が悪いと思わせるために意図的に設計されている﹂と言っている。これに対してどう思うか。

トーバルズ‥それはかつては正しかったが、もはや違う。そういう風に思う理由はいくつかあるが、今となっては、ひとつしか残っていない。残っている一つの理由は簡単なものだ。﹁あることをやる方法がたくさんある﹂

gitでは実に多くのことが行える。多くの、こう行うべきだというルールは、技術的な制約によるものではなくて、他人と協調作業をするときにそうしたほうがよいというだけのことだ。つまり、Gitはとても強力なツール群であって、最初は圧倒されるのみならず、あること、あるいは似たようなことを、複数の異なる方法で行うことができて、どれも﹁動く﹂ということだ。一般に、gitを学ぶ方法としては、おそらく、最初は基本的なことしかせずに、十分に慣れて、基本に自信がつくまで、他のことには手を出さないことだ。

gitがとても複雑であると思われていることには、歴史的な経緯がある。理由の一つに、かつては複雑だったということがある。カーネル開発のためにgitを最初期に使った者は、作業をするために、とても基本的なスクリプト集と格闘しなければならなかった。労力はすべて、基本的な技術を動かすことに使われていて、使い方を簡単にすることには、ほとんど労力が割かれていなかった。そのため、gitは当然の結果として、自分が何をしているのか完璧に理解しなければならないという印象を得てしまった。しかし、それは最初の半年か一年ぐらいのもので、今は違う。

別の大きな理由としては、gitを難しいと感じる理由は、gitは全然別物だからだ。CVSに10年や20年慣れ親しんだ者がいる。gitはCVSではない。全く似通っていない。考え方からして違う。コマンドが違う。gitはCVSに似せようとしたことなどない。実際は真逆だ。もしCVSのようなシステムを長年使っていたのであれば、gitは複雑で、不必要に変わっているように見えるだろう。もはやリビジョン番号というものはない。なぜgitはCVSにあったように、"1.3.1"のような番号と、便利なインクリメントされる番号がないのだ？　いったいこの不思議で恐ろしい40文字のHEX番号は何なのだ？　と。

だが、gitは﹁不必要に変わっている﹂のではない。変わっている部分は必要なのだ。一部の人間が複雑であると考えているだけなのだ。何故ならば、彼らは全く別の経験をすでに持っているからだ。﹁CVS経験﹂は消え去りつつある。今、多くのプログラマーはCVSなど使ったことがなく、CVSの方法をとてもわかりにくいと考えるだろう。何故ならば、彼らはgitを先に学んだからだ。

Linuxカーネル開発の速度は、Gitがなくても現在の速度に成長できたと思うか。その理由はなぜか。

トーバルズ‥まあ、﹁gitがなくても﹂成長したとは思う。しかし、それは誰か別の人間が、gitの同等品、分散型ソース管理システムでgitと同程度に効率的であるものを書く必要があっただろう。gitのようなものを我々は必要としていた。

GitHubに対する最近の考えは。

トーバルズ‥Githubは優秀なホスティングサービスだ。特に反対意見はないよ。GitHubに対する不満は、開発プラットフォームとしてのものだ。コミット、pull request、issue管理などなどが、GitHubではうまくやれない。うまいどころではなくまるで下手だ。カーネルのような開発に対しては、あまりにも制限が多すぎる。

これは、カーネルの開発体制にもよろうが、GitHubのインターフェースが、悪い方法を推奨しているせいでもある。GitHubに対するコミットは悪いコミットメッセージが書かれているなど。GitHubのWebインターフェースは、悪い行動をするように推奨しているせいである。GitHubの連中は一部を修正したので、多分多少はマシになっただろうが、Linuxカーネルの開発には適切ではない。

GitやGitHubを使った最も興味深いと思うことは？

トーバルズ‥新しいプロジェクトを始めるのがこんなにも簡単になったことに満足している。かつて、プロジェクトホスティングはとても面倒だったが、gitとGitHubのおかげで、適当な小さなプロジェクトを始めるのがとても簡単になった。プロジェクトが何であるかは重要ではない。重要なのは、誰でもできるようになったということだ。

いま温めているプロジェクトはあるか。何か素晴らしい、ソフトウェア開発の業界を何年も牛耳れるようなソフトウェアプロジェクトはあるか。

トーバルズ‥何もない。何かあったら知らせるよ。


たしかに、gitは素晴らしい。筆者にもバージョン管理ツールの重要性を認識させてくれた。筆者は、初めてバージョン管理ツールを使った時、まだgitは存在しておらず、Subversionが最も有名だった。Subversionは実にクソだったので、筆者は、バージョン管理ツールの重要性を、最近まで認識しないままであった。gitを使うのも数年遅れてしまった。gitは一瞬で気に入った。もっと早く手を出しておくのだったの公開している。