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

2005年4月3日、 Linus Torvalds が新しいバージョン管理システムの設計を始めた。 4月7日、 最初の self-hosting コミット ── つまり、 Git のソースコードが Git 自身で管理され始めた瞬間。 4月20日、 Linux カーネルの開発が正式に Git へ移行した。

設計開始から本番投入まで、 およそ10日強。 ソフトウェア工学史でも稀な速度の立ち上げである。

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

BitKeeper クライシス

2002年から2005年まで、 Linux カーネル開発は BitKeeper という商用の分散 VCS で運用されていた。 BitMover 社が開発し、 オープンソースプロジェクトには無償ライセンスを提供していた。

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

しかし2005年4月、 関係が破綻する。 OSDL の Andrew Tridgell（Samba 作者で有名） が BitKeeper プロトコルのリバースエンジニアリングを試みた ── BitMover 社が「商業 BitKeeper ユーザでありながら競合互換クライアントを作る」ことを禁じていたにもかかわらず。

BitMover 社 CEO の Larry McVoy は、 Linux カーネル開発への無償ライセンスを撤回。 Torvalds は突然、 数百万行・千人規模のプロジェクトを管理する VCS を失った。

10日間で設計された仕様

Torvalds は10年以上カーネル開発でバージョン管理の問題を見てきた経験から、 「自分が欲しい VCS」の仕様を即座に定式化できた。 公開された当時のメーリングリスト投稿から、 設計目標が読み取れる:

1. CVS の真逆: CVS が嫌いだったので、 CVS と全く違うものにする
2. 分散: 全リポジトリが等価。 中央サーバなし
3. 高速: マージ・diff・ログが体感ゼロ時間で動く
4. 完全性保証: コミット履歴は事後改竄不能（SHA-1 ハッシュ）
5. 巨大プロジェクト対応: Linux カーネル（当時800万行）が現実的に動く

特筆すべきは 内容アドレッシング（content-addressable storage） の選択。 ファイル・ツリー・コミットの全てを SHA-1 ハッシュで識別する。 つまり「ファイル名」ではなく「中身そのもの」がアドレス。 これにより、 同一内容のファイルは自動的に重複排除され、 履歴の整合性は数学的に保証される。

"Stupid Content Tracker"

Torvalds は Git を最初「the stupid content tracker（バカな内容追跡器）」と表現した。 「賢い VCS は使う側を信用しないが、 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月にメンテナを Hamano に移譲。 以後20年以上、 Hamano が Git の主任メンテナを務めている。

なぜ Git が勝ったか

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

• Mercurial（Hg）: Git とほぼ同時期に Matt Mackall が開発開始、 設計も類似
• Monotone: 2003年。 Git の内容アドレッシングに影響
• Darcs: 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 も後に Git に乗り換える（2020年）。

現代インフラとしての Git

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

• GitHub: 1億5000万ユーザ、 4億2000万リポジトリ（2024年公表）
• 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 が衝突攻撃（SHAttered） を公表して以降、 暗号学的に「安全ではない」と評価されている。 Git は2018年から SHA-256 への移行プロジェクトを進めており、 2024-2025年にかけて段階的に対応が広がりつつある。

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

何が示されたか

Git 2005 は、 「制約と必要性が極度に高まったときに、 経験豊富な設計者が10日でインフラ級のソフトウェアを生み出せる」 という事例として記録される。

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

Torvalds は Git について、 「世界を変える気はなかった。 ただ自分のカーネル開発を続けたかっただけ」と繰り返し述べている。 結果として、 彼が10日で書いたソフトウェアは、 世界中のあらゆるソフトウェアプロジェクトの記録媒体となった。