【伝説】Linus Torvaldsが「2週間」でGitを書き上げた狂気の全貌。BitKeeper失踪から生まれた、世界を変えた「配管と磁器」の設計哲学
【伝説】Linus Torvaldsが「2週間」でGitを書き上げた狂気の全貌。BitKeeper失踪から生まれた、世界を変えた「配管と磁器」の設計哲学
現代のソフトウェア開発において、Gitなしではもはや何も始まらない。GitHub、GitLab、CI/CDパイプライン、オープンソースエコシステムの全てが、このバージョン管理システムの上に成り立っている。しかし、この「神ツール」が、たった一人の男によって、わずか2週間で、怒りを燃料に書き上げられたことを知る開発者は意外と少ない。BitKeeperというプロプライエタリツールのライセンス剥奪という危機的状況下で、Linus Torvaldsが示した圧倒的な合理主義と、OSカーネル開発者としての知見を極限まで注ぎ込んだアーキテクチャ。その誕生秘話には、今なおエンジニアが学ぶべき「道具の本質」が凝縮されている。
発端：BitKeeperライセンス剥奪──「灰色で高潔な世界」が崩壊した日
2002年からLinuxカーネル開発コミュニティはBitKeeperに依存していた。分散型バージョン管理という当時としては画期的な仕組みを提供していたが、プロプライエタリであり「リバースエンジニアリング禁止」という条件が付いていた。2005年、Andrew TridgellがTelnetでサーバーに接続し「help」と入力しただけで内部プロトコルが露見することを発見、オープンソースクライアントを実装した。CEOのLarry McVoyはこれをビジネスの脅威とみなし、Linuxコミュニティへの無償ライセンスを突如剥奪。数千万行のコードを管理する基盤を失う、プロジェクト存亡の危機だった。Linusはメーリングリストで「今は灰色で高潔な世界に見える」と絶望を吐露しつつ、即座に次世代ツールの探索を開始した。
既存ツールの全否定──Subversionは「中央集権的すぎ」、Monotoneは「遅すぎ」
Linusが求めた絶対条件は明確だった。パッチ適用が3秒以内で完了すること、メンテナ同士が同期する際に一度に250個のパッチを処理できること。Subversion等の中央集権型はLinuxカーネルのスケールに耐えられないと即座に却下。唯一の実用的候補だったMonotoneは、SHA-1ハッシュとSQLiteという精神的な設計ながら、巨大リポジトリの初期化に数時間を要する性能不足で落第。さらにワークフロー哲学にも決定的な違いがあった。Monotoneはチェリーピック（特定変更の抽出）を重視したが、Linusはこれを否定した。開発を上下のヒエラルキーではなく「信頼のネットワーク」として捉え、不要になった開発枝を即座に廃棄できる構造こそがカーネル開発に必須だと考えたからだ。既存ツールへの失望は、Linusを「ゼロから究極のシステムを書く」決断へと駆り立てた。
アーキテクチャの核心：ファイル名を捨て、コンテンツアドレス可能ファイルシステムへ
Gitの革命的設計の根幹は、従来ツールが「ファイル名」をキーとしていた概念を完全に捨て去った点にある。従来はディレクトリ移動で履歴が分断されたが、Gitはファイルの内容そのものをSHA-1ハッシュ（40文字の16進数文字列）としてキー化し、直接ファイル名として保存する。このコンテンツアドレス可能ファイルシステムにより、究極の重複排除（中身が同じなら同一ハッシュ＝同一データとして1つだけ保存）と、暗号学的な完全性保証（1ビットでも改ざんされればハッシュが変わり破損を検知）を同時に実現した。ファイル移動も後から内容比較で同一性を検出するアプローチを取り、人間向けの「ファイル名」というメタデータをデータ構造から追放したのだ。
たった4つのオブジェクトで世界を表現──Blob、Tree、Commit、Tag
この極めてシンプルな構造を支えるのは、わずか4種類の基本オブジェクトだけだ。
- Blob（ブロブ）：ファイルの純粋なデータ内容のみを保持。ファイル名やタイムスタンプは一切含まない
- Tree（ツリー）：ディレクトリ構造を表現。ファイル名、権限、Blobへのポインタを持つ
- Commit（コミット）：特定時点のプロジェクト全体スナップショット。トップレベルTreeへのポインタ、作成者、メッセージ、親コミットへのポインタを保持
- Tag（タグ）：特定コミットに人間可読なリリース名等を固定するためのポインタ
データ本体とフォルダ構造を完全に分離し、Linusは最初の数日間でこれらを操作する7つのC言語プログラムを実装。複雑なデータベースソフトウェアを使わず、純粋なファイルの集合としてシステムを構築した。この無駄のなさが、Gitの圧倒的な速度と堅牢性を今日まで維持し続ける最大の要因だ。
DAG（有向非巡回グラフ）と「O(1)ブランチ」──分散開発のボトルネックを解消
4つのオブジェクトを連携させるためGitはDAGを採用した。従来ツールが履歴を1本の直線として管理していたのに対し、Gitでは各コミットが親を持ち、マージ時には複数の親を持つグラフ構造になる。この数学的構造のおかげで、プロジェクトの分岐と統合が極めて自然に表現できるようになった。ブランチ作成とは、特定のコミットを指すわずか40バイトのテキストファイルを作るだけ。物理的なファイルコピーは一切発生せず、リポジトリサイズに関わらずブランチ作成時間は常に一定。これを計算量ではO(1)操作と呼び、Linusが最もこだわったパフォーマンス哲学だ。マージにおいても共通祖先を瞬時に特定し、複数の親を持つ新たなコミットオブジェクトを作成するだけで完結。分散開発最大のボトルネックだったマージ作業が、極めて軽量で確実なものになり、「マージを日常的で安全なものに変えた最大のイノベーション」となった。
mmapによる限界突破──OSカーネル作者だからできた「バッファコピー完全排除」
アーキテクチャの美しさに加え、初期Gitの速度を支えたのは強烈なC言語チューニングだ。プログラムがディスクからファイルを読む際、通常はカーネル空間からユーザー空間へデータをコピーする処理（コンテキストスイッチ伴うオーバーヘッド）が発生する。Linuxの仮想メモリを知り尽くしたLinusは、mmapシステムコールを徹底活用。ディスク上のファイルを直接ユーザー空間のメモリアドレスにマッピングし、バッファコピーを完全排除して限界を超えるI/O速度を実現した。さらにインデックス内データはファイル名順にソートされメモリ上に構造体配列として展開され、状態比較にはC言語のmemcmp（メモリブロック直接比較関数）を使用。このOSレベルの知見による最適化により、数万ファイル規模のカーネル操作をコンマ数秒で完了させ、当時の常識を完全に覆した。「ソフトウェア設計だけでなくハードウェアの動きまで計算し尽くされていた」強靭な最適化だ。
怒涛の15日間──4日でセルフホスティング、15日でマージ実装、4月末で本番移行
2005年4月3日コーディング着手から、驚異的なスピードで開発は進んだ。着手4日後の4月7日にはGit自身のソースコード履歴管理を開始（セルフホスティング達成）。最初のコミットはユーザー向けコマンドが存在せず、標準入力をパイプで繋ぎ合わせるUNIX哲学極めたバイナリ操作で行われた。開発15日目となる4月18日には複数ブランチのマージ機能を実装、分散型バージョン管理システムとしての最低要件を完全充足。4月末にはパッチ適用ベンチマークで目標の3秒以内を大幅に下回る性能を叩き出し、同年6月16日にはカーネルのバージョン管理が完全にGitへ移行完了。中央集権的ツールへの依存を完全に断ち切り、新たな時代を切り開いた怒涛の数週間だった。
「Git」という名の皮肉──「ろくでなし」と名付けたエゴイストの誇り
イギリスの卑語で「ろくでなし、不愉快な奴」を意味する「Git」。初期のREADMEにはLinus自身による強烈な皮肉が記されている。「私はエゴイストなので自分のプロジェクトには自分の名前をつける。まずはLinux。次はGitだとね。」自分の名前と「ろくでなし」を並べる皮肉。さらに彼はこのツールを「愚かなコンテンツトラッカー」と定義した。これは決して謙遜ではなく、アーキテクチャの単純さに対する強烈な誇りだ。従来ツールがファイル変更履歴追跡のために複雑なメタデータを管理していたのに対し、Gitはただ愚直に全てのスナップショットをハッシュ化して保存するだけ。ファイルの移動や差分は後からCPUパワーを使って探索・計算すればいいという主義。Linusは後年、従来ツールの複雑な設計を「精神異常」「無意味なプロジェクト」と激しく罵っている。彼は「ソフトウェアは悪い方が良い（Worse is Better）」という単純さを主義とするエンジニアリング哲学を持つ。複雑な追跡メカニズムを捨てて事後解決に任せたことで、結果的に最も強靭なシステムが生まれた。自己犠牲のない徹底した合理主義が、このツールの本質だ。
「配管」から「磁器」へ──濱野純が支えた実用化への翻訳作業
ただし、Linusが作った初期のGitは一般のプログラマーには到底扱えない「狂気のツール」だった。彼自身も「バックエンドのインフラを作るだけで、使いやすいインターフェースを作る気はない」と割り切っていた。この狂気のツールを現在の洗練された形に育て上げたのが、濱野純（Junio Hamano）という日本人のハッカーだ。彼は2005年7月にメインメンテナを引き継ぎ、コミュニティを牽引した。Gitの構造は「配管」と「磁器」という2つの概念モデルで整理されている。Linusが最初に構築したデータ構造を直接操作する低レイヤコマンド群が「配管」。それに対し濱野さんらコミュニティが構築した、git commit、git rebase等のユーザーフレンドリーなコマンド群が「磁器」。強固なインフラの上に美しく使いやすい操作系統が丹念に構築されていった。この地道な人間工学への翻訳作業がなければ、Gitが世界中に普及することはなかったはずだ。天才が生み出した破壊的なインフラを実用的な製品へと磨き上げた、素晴らしいコミュニティの連携だ。現在もGitが多くの開発者に愛されている理由は、この「配管と磁器」の明確な役割分担にある。技術の根幹とユーザーの使い勝手が見事に融和した結果と言える。
ネットの反応
4日でセルフホスティング達成はヤバすぎる。Linusの集中力が化け物じみてる
mmapの使い方見て「OS作ってる人違うな」ってなった。カーネル知識をユーザーランドに持ち込む発想が凄い
濱野さんがいなきゃGitは普及してなかったろうな。配管と磁器の分離は本当に偉大
「ソフトウェアは悪い方が良い」のLinus版を見た気がする。複雑な追跡捨ててスナップショットだけで正解だった
BitKeeperのライセンス剥奪がなければGitは生まれてなかった。ピンチをチャンスに変えた好例
Monotone落とされた理由が「チェリーピック重視」なの納得。Linusの「信頼のネットワーク」観が徹底されてる
SHA-1でコンテンツアドレス可能にする発想、今だと当たり前だけど当時は革命的だったんだな
O(1)ブランチのおかげでトピックブランチ戦略が当たり前になった。これなくして現代開発はありえない
AIの所感
Git誕生の物語は、単なる「ツール開発成功譚」ではない。「制約条件下での最適解を、妥協なく追求したときに何が起きるか」の教科書だ。Linusが直面したのは「BitKeeperという黒箱への依存を断ち切り、Linuxカーネル規模に耐え、分散開発の信頼ネットワークを支えるシステムを、今すぐ作れ」という極限の制約だった。それに応えたのが、ファイル名という人間向けメタデータを捨て去り、コンテンツそのものをキーにするというラディカルな設計判断、DAGによる分岐統合の数学的モデル化、OSカーネル作者としての知見をユーザーランドに降ろしたmmap活用というハードウェア密着最適化だ。これらは全て「速度」「堅牢性」「分散性」という本質的要求に対して、枝葉末節を一切切り捨てて答えを出した結果に他ならない。そして濱野純による「配管から磁器へ」の翻訳作業は、天才の作った「正しいが使えない道具」を「正しくて使える道具」へと昇華させた、コミュニティ主導エンジニアリングの模範例だ。現代の開発者がGitを「当たり前のインフラ」として使えるのは、この二人の合理主義と、それを支えた無数の貢献者たちの積み重ねの上に成り立っている。新しいツールを設計するとき、あるいは既存ツールに不満を持ったとき、「Linusならどう切り捨てるか」「濱野さんならどう磨くか」を問い直すことが、本質的なイノベーションへの近道になるだろう。Gitがない世界には、もう絶対に戻れない。