原文は 4 月 6 日に掲載されました。原文へのリンクはこちらです。

10 年前の今週、Linux カーネル コミュニティは困難な問題に直面しました。すなわち、バージョン管理システム BitKeeper を使うことができなくなり、他のソフトウェア構成管理 (SCM) システムも分散システムのニーズを満たすことができませんでした。Linux の生みの親 Linus Torvalds は自らこの困難に立ち向かい、週末をはさむ 10 日間くらいの間雲隠れし、翌週には Git を持って登場しました。今日、Git は何千というプロジェクトで利用されており、プログラマーの間に新しいレベルのソーシャル コーディング形態をもたらしました。

 

この記念すべきマイルストーンを祝うために私たちは Linus に Git の舞台裏やこのプロジェクトに対する彼の考え、またこのプロジェクトがソフトウェア開発に与えた影響について話してもらいました。本記事は彼のコメントです。この質疑応答に続く 1 週間を Git 週間として、このバージョン管理システムを使っているいろいろなプロジェクトを特集し、日替わりで KVM、Qt、Drupal、Puppet、Wine を取り上げます。

 

なぜ Git を作ったのですか? 

 

Torvalds: 私は本当は SCM システムの開発に携わりたいとはちっとも思っていませんでした。むしろコンピューターの世界で (データベースを例外として) 一番おもしろくないことだと思っていました。そしてすべての SCM が大嫌いでした。しかし、そこに BitKeeper (BK) が登場し、私はソース管理の見方を変えました。BK がほとんどのことを正しく実行し、リポジトリのローカル コピーを持ち、分散して開発したものをマージするのはすばらしいことでした。分散ソース管理の重要性は、SCM の主要な問題点の 1 つ、すなわち、「誰が変更できるのか」ということにからんだ原理・原則の問題を解決してしまうことです。BK は、すべての人にそれぞれのソース リポジトリを持たせることででそれが避けられることを示しました。しかし、BK にも問題はありました。問題になるような技術的選択がいくつかあり、リネーム関連の問題は特に不評でしたが、一番のマイナス面はオープン ソースではなかったために利用したくないという人がたくさんいたことです。ですから BK を利用するコア メンテナーが出始める一方で (オープン ソース プロジェクトでは自由に利用できたので)、広く利用されることはありませんでした。カーネル開発の助けにはなりましたが、痛点もあったのです。

 

BK の利用規約に反することでしたが、Tridge (Andrew Tridgell) がかなり単純な BK プロトコルのリバース エンジニアリングを始めると、BK 利用の是非を巡る問題は頂点に達しました。私は数週間 (数か月にも思えました) の間 Tridge と Larry McVoy (BitKeeper 社の CEO) の間を仲介しようとしましたが、最終的にはうまく行きませんでした。そこで、ある時点からもう BK は使えないという結論に達しましたが、私は BK 以前の不便な時代には戻りたくありませんでした。悲しいことに、その当時、分散ソース管理を試みる SCM はいくつかあったものの、どれもリモート環境ではうまくいきませんでした。利用できる SCM はリモート環境での性能要件を満たすことができませんでした。またコードの完成度とワークフローについても心配だったので、最終的に自分でコードを書くことにしたのです。

 

どのようにアプローチしたのですか? その週末は寝ずにずっと書いていたのですか? それとも普通の時間に書いたのですか? 

 

Torvalds: 実際にどのように形になっていったかについては、最初の 1~2 日の間に作った部分以外は git ソース コード リポジトリで見ることができます。git 自体を使って git にソース コードをコミット (「セルフ ホスティング」) することができるようになるのに約 1 日かかりました。そのため、1~2 日目あたりは見ることができませんが、それ以外はすべて残っています。コーディングは殆ど日中に行いましたが、真夜中にリポジトリに登録した箇所もあれば、午前 2 時だったのも数か所あります。最も興味深いのは、非常に速く形になったということです。git ツリーの最初のコミットはたくさんのコード量ではなかったものの、既に基本的な機能を備えており、git 自体にコミットすることができました。重要なのはコーディングの分量ではなく、データを整理する方法を考え出すことでした。

 

約 10 日間でできあがりはしましたが (この時点で私は初めて git を使って「カーネル」コミットをしました)、私が強調したいのは、猛然とコーディングしたというようなことではありません。初期のコードの実際の分量は比較的小さく、すべては基本的な考えを正しく実現することにかかっていました。また、私はプロジェクトを始める前にじっくり考えました。他の SCM の問題を十分に検討しました。やってはいけないことを十分に検討しました。

 

それはあなたの期待に沿うものとものとなりましたか? 現在、どのように評価していますか? 制約はありますか? 

 

Torvalds: 私は git にとても満足しています。カーネルにとってうまく機能していますし、いまだに私の期待に沿っています。また興味深いのは、git がどのようにして他の SCM システムに取って代わったかです。それも結果的には驚くほど速く。CV や RCS が長く存在しているのを見ると、ソース管理システムを変更するにあたっては慣性力が働いていることがわかります。しかし、ある時点で git が取って代わるようになってしまいました。

 

どうして幅広く採用されるようになったと思いますか? 

 

Torvalds: 私が SCM を嫌いになったのと同じ理由で他の大勢の人がイライラししていたのではないでしょうか。そして人々を激怒させるような問題を 1 つ 2 つ解決しようとした SCM プロジェクトはこれまでにたくさんありましたが、git のように直接的に大きな問題に対応したものはありませんでした。人々が「分散」の部分が大切だと認識していない状況でも (多くの人がその「分散」を実現すべく戦っていましたが)、git が簡単で信頼できるバックアップを可能とし、セントラル リポジトリに対する書き込みアクセス権限の原理・原則を気にすることなく自身のプライベート テスト リポジトリを作ることができることがわかると、もう後戻りはしません。

 

Git は永遠に続きますか? それとも今後 10 年の間に別のバージョン管理システムを見込んでいますか? あなたがそれを書きますか? 

 

Torvalds: 書くつもりはありません。また 10 年後には新しいものが出現するかもしれませんが、「git のようなもの」になるのは間違いありません。git がすべて正しくできたというわけではありませんが、今までにどの SCM もできなかった方法で本当に基本的な問題を解決しました。

 

偽ってまで謙虚なふりはしません;) 。

 

なぜ Git は Linux に適しているのですか? 

 

Torvalds: 明らかに私たちのワークフローのために設計されているというのが理由のひとつです。git は Linux の一部です。すでに何度も「分散」の部分に触れていますが、繰り返し強調するだけの値打ちがあります。Linux のような大きなプロジェクトにとって、十分に効率的であるようにも設計されています。また、git が登場するまで人々が「難しい」と思っていたことができるように設計されています。なぜならそれは私が毎日することだからです。

 

例を挙げると、「マージ」という概念はほとんどの SCM において一般的にはかなり骨が折れ、難しいと思われてきました。大変なことなので、普通はあなただけのマージという形になります。私はマージ ウィンドウで作業する時、一日に何十ものマージを行う必要があり、従来の SCM が行っていたレベルでは不十分なのです。そういうときに、一番力をかける作業はマージそのものではなく、でき上がったカーネルをテストすることであるべきです。マージにおける git 部分はほんの数秒くらいで、マージを説明するメッセージを書く方にずっと多くの時間を費やすべきなのです。

 

git は基本的に私の要件を満たすために設計され書かれたのであり、そのことがよくわかります。

 

人々は Git が頭のいい人だけのものだと言います。Andrew Morton でさえも、Git は「自分が思っていたほどには頭が良くなかったと思わせるように特別に設計されている」と言っています。これについてどう思われますか? 

 

Torvalds: かつてはそうだったかもしれませんが、今は違います。いくつかの理由があって人々はそのように感じてしまうのですが、現在ではそのうちの 1 つしか残っていないと思います。残っている理由はかなり単純です。「いろいろな方法が用意されている」ということです。

 

git を使えばいろいろなことができます。そして「やるべき」ことに関するルールの多くはあまり技術的制約によるものではなく、他の人々と作業をするときに何がうまく機能するかに関するものなのです。git は非常に強力なツールの集合であり、当初人々を圧倒するだけでなく、同じこと (あるいは似たようなこと) を違う方法で行うことができ、それらのすべてが「うまくいく」のです。一般的に git を学ぶ最適な方法は、最初はごく基本的なことだけを行い、基本を習熟して自信が持てるようになるまでは、その他のできることには目もくれないという方法です。

 

git が複雑と思われたのには、いくつかの歴史的な理由があります。その 1 つは実際に複雑であったということです。カーネルの作業をするためにごく初期に git を使い始めた人たちは、あらゆるものを動かすために大変な数のスクリプト一式を覚えなければなりませんでした。中核技術を利用できるものにすることにすべての努力が注がれ、逆に簡単でわかりやすくするための努力はほとんどされませんでした。初期の頃の git は、自分がその前に何をしたかを正確に理解していなければ使えないという悪評を買っていました。これは主に最初の半年から 1 年について言えることでした。

 

人々が git は難しいと思ったもう 1 つの大きな理由は、git が特異なものだということでした。10～20 年間 CVS を使っている人はいましたが、git は CVS ではありませんし、CVS に近いものでさえありません。概念が異なります。コマンドが違います。git は CVS に似せようとする努力はせず、むしろ逆でした。もしも CVS のようなシステムを長く使っていたとしたら、git は複雑で不必要なまでに違ったシステムに見えます。人々は奇妙な改訂番号に当惑しました。git の改訂版はなぜ CVS のようにきれいに増加する番号で ”1.3.1” のようにならないのか? どうして奇妙で恐ろしげな 40 文字の 16 進数なのか? 

 

しかし、git は「不必要なまでに違う」わけではありませんでした。違いは必要なのです。両者が非常に違うバックグランドを持っていることから、一部の人たちに実際よりも複雑だと思われてしまったのです。「CVS バックグランド」的な要求は消えつつあります。今ではむしろ、CVS を使ったことがなく git をまず覚えてしまい、CVS のやり方に困惑するプログラマーもたくさんいるでしょう。

 

Linux カーネル開発は Git なしに現在の成長率で成長できたと思いますか? それはなぜですか? 

 

Torvalds: 「git なし」でももちろん成長できたでしょう。しかし、その場合は git と同等のものを誰かほかの人が書く必要がありました。すなわち、git と同じくらい効率的な分散 SCM です。絶対に git に「似たような」ものは必要でした。

 

GitHub に関するあなたの考えはどうですか? 

 

Torvalds: GitHub はすばらしいホスティング サービスです。これに反対する気持ちはまったくありません。私が聞いた不満は、GitHub が開発プラットフォームとして全然うまく作動しないということです。すなわち、コミットやプル要求をしたり、問題点の追跡をするようなときです。カーネルのようなものにとってはまったく意味がありません。制約が多すぎます。

 

それは部分的にはカーネルの開発方法に要因がありますが、GitHub のインターフェイスが間違いを誘発させていることにも原因があります。GitHub の Web インターフェイスが間違いを誘発していたために、GitHub 上のコミットは誤ったコミット メッセージを出すことなどがありました。それらは一部修正したので改善されていると思いますが、Linux カーネルのようなものに関しては今後も適切であることは決してないでしょう。

 

Git や GitHub の最も興味深い利用方法はどのようなものですか? 

 

Torvalds: 新しいプロジェクトをとても簡単に始められるようになったことは素直にうれしく思っています。プロジェクトをホストすることはかつては非常に大変でしたが、git や GitHub によって、いろいろな小さいプロジェクトを簡単に行えるようになりました。プロジェクトがどのようなものかというのは関係ありません。できるということが大事なのです。

 

とっておきの脇道プロジェクトや、今後数年間のソフトウェア開発に影響を及ぼすすばらしいソフトウェア プロジェクトはありませんか? 

 

Torvalds: 今のところ計画はありません。でも何か変化があればお知らせします。

 

Atlassian も Git の 10 周年記念を祝っています。これまでの軌跡をたどるには下のイメージをクリックしてください。