Git 20周年の振り返り – 今なお奇妙で、今なおクールなツール

• Gitは20年前、Linus Torvaldsが最初のコミットを行ったことから始まったバージョン管理システムである
• もともとは単純な個人プロジェクトだったが、その後、世界で最も広く使われるバージョン管理システムへと成長した
• 筆者はGitHubの共同創業者であり、Git関連の書籍やコミュニティの構築を通じてGitの発展に深く関わってきた
• 初期は単純なディレクトリ内容管理ツールだったが、今ではソフトウェア開発のあり方を変えた中核ツールになっている

Gitの哲学と必要性

• Gitは、Linuxカーネルコミュニティが既存のバージョン管理ツールの限界に不満を抱く中で誕生した
• 以前の協業方式は、メーリングリストとtarball、patchファイルを通じた分散的かつローカルベースのコラボレーションだった
• 当時のSCMツールは遅く、中央集権的で非効率だったため、tarball/patchベースのやり方の方が優れていた
• Bitkeeperというツールが代替案だったが、ライセンス問題によりGitの開発が始まった
• Gitは最初から「バージョン管理システム」ではなく、patchとtarballをよりうまく扱うためのデータ構造として設計されていた

Gitの最初のコミット

• 最初のコミットは、ごく基本的なディレクトリ内容追跡ツールだった
• 当時のツールはgit commitのようなコマンドではなく、write-tree、commit-treeなどの低レベルなデータベースツールだった
• Gitは最初から次のような機能を備えていた:
  • 作業ディレクトリをキャッシュに保存し（update-cache）、ツリーとしてオブジェクト化し（write-tree）、データベースに記録
  • 変更内容をコミット形式で保存し（commit-tree）、履歴を生成
  • cat-file、read-tree、show-diffでデータベースオブジェクトを読み取り、比較
• LinusはGitを単なるバックエンドの「配管ツール（plumbing）」と見なし、UIは外部で作られることを望んでいた

Gitを使ったコンテンツ配信の事例

• 筆者は2005年、Reactrixというスタートアップでデジタル広告コンテンツ配信用にGitを使用した
• 何百台ものデジタルディスプレイがそれぞれ異なる広告の組み合わせを持つ必要があり、Gitのコンテンツアドレス化機能がこれを効率的に解決した
• Gitをコード管理ではなくコンテンツ配信ツールとして使った創造的な事例だった
• 初期Gitプロジェクトの主要コントリビューターだったNick Hengeveldが、SSLや並列HTTP転送などの機能を追加した
• この経験がGit関連のドキュメント、Webサイト、書籍を作るきっかけとなり、GitHubへとつながっていった

Gitコマンドとユーザーツールの進化

• 初期のGitコマンドはすべて低レベルのスクリプトベースツールで、現在とは大きく異なっていた
• git log、git rebase、git commitなどのコマンドも当初は単純なシェルスクリプトであり、その後徐々に発展して現在の形に定着した

git logの初期バージョン

• git logはgit-rev-list --pretty HEAD | lessという形のシンプルなスクリプトだった
• rev-listは現在も存在するコミットID出力用ツールである

git rebaseの登場

• rebaseという概念は、2005年のLinusとJunio Hamanoのメールでのやり取りから生まれた
• Junioの作業方式は、既存のHEADを捨てて新しいHEADを基準に作業を続けるというもので、それを「rebase」と表現した
• これが現在私たちの知るgit rebaseコマンドへと発展した

Octocatの起源

• GitHubの象徴であるOctocatは、Gitにおける「octopus merge」戦略から着想を得ている
• 複数のブランチを同時にマージする戦略を「octopus」と呼び、GitHub初期、この言葉に着想を得てOctocatキャラクターが生まれた

Gitの現在と未来

• 筆者は今でもGitを本来の目的どおり「stupid content tracker」として活用している
• GitButlerプロジェクトでは、Gitを使ってプロジェクトの履歴を追跡し記録する方法で活用している
• Gitは今なお強力なコンテンツ追跡および分散システムであり、今後もさまざまな形で活用される可能性がある

• お誕生日おめでとう、Git。今なお奇妙で、今なおクールなツール

[aobamisaki]

Git の20歳の誕生日、おめでとうございます。

[bobross0]

おめでとう

[girr311]

お誕生日おめでとう。おじさんの言うことをよく聞いて、いつまでも元気でいてね。

[kaistj]

お誕生日おめでとうございます ^^

[crawler]

なんだか妙にテンションが上がる投稿ですね、これ。

[GN⁺]

Hacker News の意見

• Git の起源に関する話では、Linus が預言者のように描かれる傾向がある

  • ブログ記事は Linus の人間的な側面を強調し、初期の試行錯誤にも触れている
  • Mercurial も重要な役割を果たしたが、しばしば見過ごされている
  • Mercurial は最初から UI を備えており、Subversion に似た UI で使いやすかった
  • Git のデータ構造は大容量ファイルには向いていない
  • Git が必然だったとは思わず、新しい代替が現れることを期待している

• 2002年ごろ、プロジェクトの各部分に固有のハッシュコードをタグ付けするというアイデアを持っていた

  • ソフトウェア企業に提案したが、関心は得られなかった

• ClearCase の代替として Git を使い始めた

  • 2007年ごろから Git を使い始め、ClearCase の不便さを解消するためにスクリプトを書いた
  • 2008年には Git にパッチを投稿し始め、オープンソースへの貢献について多くを学んだ
  • Git の複雑な CLI にもかかわらず、使うのに苦労はしなかった
  • 次の職場では Chromium のフォークをベースに作業し、Git を使ってマージコンフリクトを解決することに習熟した
  • GitHub が Git の主要なコードレビュー手段になったことには失望したが、Mercurial より Git のほうがよい選択だと思っている

• Git がまだ20年しか経っていないことに驚く

  • GitHub が20年未満であることには驚かないが、Git が2005年以前には存在しなかったというのは衝撃的だ
  • 他のソース管理の選択肢を使ったことがなく、これから先も使うことがあるのか気になる

• 歴史的な文脈を知ることができて興味深かった

  • ClearCase も rebase という用語を使っており、1999年から使われていたことが確認できる
  • ClearCase の rebase は時間がかかったが、Git の即時の rebase には驚かされた

• 効率的な tarball 履歴データベースツールを作りたかったのであり、バージョン管理システムを作る意図はなかった

• コミットを ssh キーで署名できることを知った

  • OpenBSD での問題を解決するために ssh 署名の方法を使った
  • CVS から Git に作業項目を移して20年も経ったとは思えない

• 有用な記事に感謝し、Git の内部構造の紹介を含むリポジトリを勧めている

• メーリングリストでの協業についてブログ記事を書きたいという意見が興味深い

• 多くのソース管理システムの中で、Git は使い勝手が最も悪いが、最も好きなシステムでもある