Git 公開 ── Torvalds が10日間で書いた分散バージョン管理

2005年4月3日、 Linus Torvalds が新しいバージョン管理システムの設計を始めた。 4月7日、 最初のコミット e83c516「Initial revision of "git", the information manager from hell」 ── Git のソースコードが Git 自身で管理され始めた瞬間。 4月16日、 Linux カーネル本体（2.6.12-rc2、 671万8755行） が最初のコミット 1da177e として Git リポジトリに取り込まれた。 Git が管理した最初のカーネルリリースは6月16日の 2.6.12 である。

設計開始からカーネル本体の取り込みまで、 13日。 Torvalds 自身の要約は「it was about 10 days until I could use it for the kernel」（2025年の GitHub Blog インタビュー）。 ソフトウェア工学史でも稀な速度の立ち上げである。

なぜこの速度が可能だったか、 そしてなぜ Git が CVS / Subversion / Perforce などの先行する VCS を全て退けて世界標準になったか ── それを理解するには、 2005年4月の数週間に何が起きていたかを追う必要がある。

BitKeeper クライシス

2002年から2005年まで、 Linux カーネル開発は BitKeeper という商用の分散 VCS で運用されていた。 BitMover 社が開発し、 オープンソースプロジェクトには無償ライセンスを提供していた。 Torvalds 自身、 破局を告げた投稿で「We've been using BK for three years」と書いている。

選定した動機は明快だった。 当時の OSS 系 VCS（CVS、 Subversion） はすべて中央集権型で、 数千人が並列に貢献する Linux カーネルの規模に耐えなかった。 BitKeeper は分散モデルを採用しており、 性能と機能で唯一現実的な選択肢だった。

しかし2005年4月、 関係が破綻する。 OSDL の Andrew Tridgell（Samba 作者で有名） が、 BitKeeper の無償版が表示しないリビジョンメタデータを取り出すクライアントを作った。 無償版のライセンスはその利用者が競合 SCM の開発に関与することを禁じていたが、 Tridgell はそのライセンスに同意しないままプロトコルを解析していた。

BitMover 社は無償版の提供停止を発表し、 Tridgell の作業をその理由に挙げた。 一部のカーネル開発者には無償の商用ライセンスを提示したが、 OSDL 所属の Torvalds と Andrew Morton は対象外だった。 サポートの正式終了は2005年7月1日。

2005年4月6日、 Torvalds は LKML に「Kernel SCM saga..」と題した投稿を出す。 責任の所在について彼はこう書いた ── 「Btw, don't blame BitMover, even if that's probably going to be a very common reaction. Larry in particular really did try to make things work out」。 そして末尾の追伸は、 代替候補についての彼の見立てをそのまま示している ── 「Don't bother telling me about subversion. If you must, start reading up on "monotone"」。

10日間で設計された仕様

「10日」は瞬間芸ではない。 Torvalds は2015年の Linux Foundation のインタビューで「It all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started」と述べ、 2025年には構想の開始を前年の11〜12月に置いている。 コードを書き始めた時点で、 仕様はすでに頭の中にあった。

Git プロジェクト自身が記録する当初の設計目標は5点である:

1. 速度
2. 単純な設計
3. 非線形開発への強い対応（数千の並行ブランチ）
4. 完全な分散（全リポジトリが等価。 中央サーバなし）
5. Linux カーネル級の大規模プロジェクトを効率的に扱えること（速度とデータ量の両面で）

5番目が具体的に何を意味したかは、 4月16日の初回インポートが示している ── 671万8755行の追加を1コミットで受け止める。

特筆すべきは 内容アドレッシング（content-addressable storage） の選択。 初版 README はこう書いている ── 「The object database is literally just a content-addressable collection of objects. All objects are named by their content, which is approximated by the SHA1 hash of the object itself」。 つまり「ファイル名」ではなく「中身そのもの」がアドレス。 これにより、 同一内容のファイルは自動的に重複排除され、 履歴の整合性は数学的に保証される。

"Stupid Content Tracker"

初版 README の1行目は「GIT - the stupid content tracker」だった。 続けて Torvalds は、 "git" は気分次第で何とでも読める語だと書く ── 「stupid. contemptible and despicable. simple」、 機嫌が良ければ「global information tracker」、 壊れたときは「goddamn idiotic truckload of sh*t」。

信頼モデルの割り切りも README に明記されている ── 「"git" itself only handles content integrity, the trust has to come from outside」。 ハッシュが保証するのは改竄がないことだけで、 その履歴を信用してよいかは Git の外側（署名されたタグなど） が決める。

最初の Git は、 現代の Git のような「使いやすい CLI」ではなかった。 git commit-tree、 git update-ref、 git read-tree など、 内部データ構造を直接操作する低レベルコマンド（plumbing） の集合だった。

「使いやすい上位コマンド（porcelain）」 ── git commit、 git checkout、 git merge ── の整備は、 2005年後半以降、 Junio Hamano（濱野純） を中心に進められた。 Torvalds は2005年7月26日にメンテナを Hamano に移譲。 以後20年以上、 Hamano が Git の主任メンテナを務めている。

なぜ Git が勝ったか

2005年時点で、 OSS 系の分散 VCS は他にもあった。

• Mercurial（Hg）: Git とほぼ同時期に Matt Mackall が開発開始、 設計も類似
• Monotone: 2003年。 内容アドレッシングの先例。 Torvalds が4月6日の投稿で唯一名指しした「最も有望な代替」
• Darcs: 2003年公開（開発は2002年から）。 パッチ理論に基づくが速度に難
• Bazaar（Bzr）: 2005年。 Canonical（Ubuntu） がサポート

Git が他を退けた理由は、 主に2つ。

1. Linux カーネルという旗艦プロジェクト: 世界最大級の OSS プロジェクトが Git で運用されているという事実そのものが、 強力な参照モデルとなった。 Linux の規模で動く道具なら、 他のどのプロジェクトでも足りないはずがない。

2. GitHub（2008年）: Git の使いにくさを Web UI で隠蔽し、 ソーシャル機能（fork、 pull request、 issue） を追加した GitHub の登場で、 Git は突然「個人開発者にとっても扱える」道具になった。 Mercurial を主力としていた Bitbucket も、 2020年7月1日に Mercurial のサポートを打ち切って Git に一本化した。

現代インフラとしての Git

2026年現在、 Git の支配は完全に近い:

• GitHub: 1億8000万超の開発者、 6億3000万リポジトリ（GitHub 自身が公表する Octoverse 2025 の数字）
• GitLab: 自己ホスト型として企業の標準
• Bitbucket: Atlassian 系統の開発者向け
• Gitea / Forgejo / Codeberg: GitHub 代替の OSS フォージ

Git は単なる VCS ではなくなった:

• CI/CD: Git push がデプロイのトリガー
• GitOps: Kubernetes のクラスタ状態を Git リポジトリで管理
• コードレビュー: Pull Request が標準ワークフロー
• AI 訓練データ: GitHub のパブリックリポジトリが LLM の学習データ
• インシデント対応: コミット履歴がフォレンジック証拠

「Linus Torvalds が10日で書いたソフトウェア」が、 20年後に世界の知的生産活動の記録機構となった。

SHA-1 から SHA-256 へ

Git の核となる SHA-1 ハッシュは、 2017年に Google と CWI Amsterdam が衝突攻撃（SHAttered） を公表して以降、 暗号学的に「安全ではない」と評価されている。 Git 2.29（2020年10月） は git init --object-format=sha256 による SHA-256 リポジトリの実験的サポートを入れた。 ただし SHA-1 リポジトリとの相互運用は未実装のままで、 主要なホスティング事業者も SHA-256 リポジトリを受け入れていない。 移行は20年目の Git がなお抱える宿題である。

ただし「内容アドレッシング」という設計原理自体は不変で、 ハッシュ関数を SHA-256 に差し替えても Git のメンタルモデルは変わらない。 これは Torvalds が10日間で書いた設計の長期的堅牢性を示している。

コラボレーションの基本単位を定義し直した

Git 2005 が示すのは、 制約と必要性が極度に高まったとき、 経験豊富な設計者は10日あまりでインフラ級のソフトウェアを生み出しうるということである。 ただし Torvalds 自身が釘を刺すとおり、 その10日を可能にしたのは、 それ以前の数か月の思考である。

しかしより重要なのは、 分散バージョン管理という抽象が、 単なる開発ツールを超えて 「コラボレーションの基本単位」 を再定義したことだ。 Pull Request、 Code Review、 Branch、 Merge ── これらの語彙は2026年現在、 エンジニアだけでなく、 翻訳家・データサイエンティスト・ライターのワークフローにまで浸透している。

Torvalds が4月6日の投稿で書いた目的は、 世界を変えることではない。 BitKeeper が可能にしていた作業をこれからも続けられるよう、 道具一式を整えること ── それだけだった。 結果として、 彼が10日あまりで書いたソフトウェアは、 世界中のあらゆるソフトウェアプロジェクトの記録媒体となった。