現在のソフトウェア開発を支えている Git だが、その最初のコミットを読んだことがある人は多くないだろう。2005年4月7日、Linus Torvalds が記録した初回コミットの件名は、次のようなものだった。

Initial revision of “git”, the information manager from hell

（和訳）”git” ——地獄から来た情報管理ツール——の最初のリビジョン

20年後に世界標準となるツールの、作者自身による初日の位置づけである。同梱された README で、Linus は「git」という名前の由来を、やや自嘲的に4つ挙げている。

“git” can mean anything, depending on your mood.

• random three-letter combination that is pronounceable, and not actually used by any common UNIX command.
• stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
• “global information tracker”: you’re in a good mood, and it actually works for you.
• “goddamn idiotic truckload of sh*t”: when it breaks

（和訳）「git」は気分次第でどんな意味にもなる。

• 発音しやすく、一般的なUNIXコマンドと被らない3文字の組み合わせ。
• stupid（低俗）、contemptible（卑劣）、simple（単純）。スラング辞典から好きに選べ。
• 「global information tracker（世界規模の情報追跡機）」：機嫌がいい時。実際ちゃんと動いてくれる。
• 「goddamn idiotic truckload of sh*t（大バカ野郎のクソの山）」：壊れた時。

名前の付け方こそ砕けているが、この記事で確認したいのはその中身だ。荒削りだった初日のソースコードと、そこに既に完成していた設計思想の対比である。

荒削りだった初日

初回コミットの状態を実際に取り出してみると、その素朴さがよく分かる。

• C言語のソースは合計およそ1,000行
• コマンドは7個のみ（init-db、cat-file、commit-tree、read-tree、write-tree、update-cache、show-diff）
• 現在の git add や git commit はまだ存在せず、低レベルな「配管（plumbing）」コマンドを直接実行する前提

使い勝手について、Linus 自身も2番目のコミット（”Add copyright notices”）のメッセージで率直に認めている。

The tool interface sucks (especially “committing” information, which is just me doing everything by hand from the command line)

（和訳）このツールのインターフェースはひどい（特に情報の「コミット」は、コマンドラインから手作業で全部やっているだけだ）。

実装の素朴さは、オブジェクトを取り出す cat-file.c が全23行で書かれている点にも表れている。cat と名乗りながら内容を標準出力へ出さず、一時ファイルに書き出してそのパスを表示するだけで、書き込みに失敗しても種別を “bad” に置き換えてそのまま終了する。エラー処理も含め、まだ「動く実用ツール」以前の、アイデアを形にした段階だと分かる。

初日から完成していた核

興味深いのは、インターフェースや実装が素朴である一方で、Git の中核をなす設計は初回コミットの時点ですでに固まっていたことだ。README には、次の要素がそのまま記述されている。

• オブジェクトDBは content-addressable ——すべてのオブジェクトを、その内容の SHA1 ハッシュで名付ける
• オブジェクトは3種類 —— blob（ファイル内容）、tree（ディレクトリ）、changeset（現在の commit）
• 整合性は内容から独立に検証できる。信頼（trust）は Git の外側から与えるものとし、Git 自身が保証するのは内容の完全性（integrity）だけ

これらは、現在の Git をそのまま説明する内容でもある。名前や操作性は後から大きく変わったが、データ構造の考え方は初日から一貫している。

設計が目先の要件より先を見ていたことは、commit-tree.c に残る次のコメントにも表れている。

Having more than two parents may be strange, but hey, there’s no conceptual reason why the file format couldn’t accept multi-way merges. … I don’t really expect that to happen, but this is here to make it clear that conceptually it’s ok..

（和訳）親が2つより多いのは奇妙かもしれないが、多方向マージをこのファイル形式が受け付けられない概念的な理由はない。実際に起きるとは思っていないが、概念上は問題ないと明示するために書いておく。

後年に一般化する「オクトパスマージ」を、必要になる前から設計の器に含めていたことになる。実装の完成度ではなく、扱う概念の空間を先に正しく定義していた例だと言える。

AI時代の設計に引きつけて

この初日の姿は、AI がコードを書く時代の開発にそのまま接続できる。初期の Git が示しているのは、次の優先順位である。

「動くかどうか」より「概念が正しいかどうか」を先に固める。

荒いコードは書き直せるし、エラー処理は後から補える。事実、Git はその後メンテナの手で git add / commit / push といった使いやすい体系を獲得していった。表層は後から整えられる。一方で、初日に選んだデータ構造そのものが誤っていれば、それは後から直しにくく、作り直すことになる。

AI時代の開発も構造は同じだ。コードの実装・修正・書き直しは、AI が担う領域が広がっていく。だからこそ人間が引き受け続けるべきは、その下にある概念設計とデータ構造の判断である。何を不変とし、何を後から直せるものとするか。この線引きは判断であり、責任を伴う仕事として残る。

まとめ

• Git の初回コミットは、作者自身が「地獄から来た情報管理ツール」と呼ぶ、約1,000行・7コマンド・git add すら存在しない素朴な実装だった
• その一方で、content-addressable、SHA1、blob / tree / commit という核の設計は初日から固まり、20年間一貫している
• 表層は後から整えられ、土台だけは初日に正しく定義されていた
• AI がコードを書く時代に人間が握るべきは、「動くか」より「概念が正しいか」という、この優先順位そのものだ

最初の実装は素朴でよい。土台となる設計だけは、初日から正しく定義しておきたい。