Gitの基本情報
こんにちは、OSSのレキシラジオです。
このポッドキャストでは、エンジニアであるhentokoは、
毎週一つのOSSプロジェクトを取り上げて、
そのプロジェクトにまつわる歴史を紹介する番組になります。
今週のテーマは、Gitのレキシについてです。
それでは見ていきましょう。
まずはGitについて、簡単に説明したいと思います。
Gitはですね、主にCやRubyなどの
様々なプログラミング言語で書かれたアプリケーションコードを
バージョン管理して、いつでも昔のバージョンに戻すことができるような
バージョン管理システムになっています。
またですね、近年においては、
アプリケーションコード以外にも文章の管理のために
利用されている方もいたりします。
現在ではですね、全世界の開発者の
93%以上が利用されているようなツールになっています。
Linuxカーネルの開発背景
これによって、事実上の
世界標準となっていると言えるかなと思います。
このGitなんですけど、もともとはですね、
LinuxKernelの開発のために開発された
Linux作者のLinus Torvaldsが開発したシステムになっています。
さてここからはですね、
Gitが開発された背景、なぜ開発されたのか
というところを見ていけたらなと思います。
まずGitなんですけど、先ほどもご紹介した通り、
GitというのはもともとLinuxKernelの開発のために
開発されたツールになっています。
そちらのLinuxKernelなんですけど、
LinuxKernelの開発チームはですね、
1991年から開発の方が始まっているんですが、
約10年間、2002年までですね、
実はLinuxKernelの開発チームというのは
バージョン管理システムというのを使っていませんでした。
じゃあどうやって開発というのを進めていたかというと、
これはびっくりなんですけど、変更作文というのを
作文ファイルというパッチというような形で
まとめてですね、メーリングリストで共有し、
ここでオーナーであったLinux自身が主導で適用し、
ソースコードをリリースするというような
原始的な手法をとっていました。
当時から実はバージョン管理システムというのは
存在していたんですけど、LinuxKernelチームでは
使っていなかったというところがあります。
当時のですね、90年代のバージョン管理システムというのは
コンカレントバージョンシステムと呼ばれるCVSというものと、
それの改良にあたるサブバージョンSVNというのが
主流でした。
これらのバージョン管理システムというのはですね、
中央集権的に単一の中央サーバーがあることというのを
前提としたシステムになっていました。
なんですけど、そういった中央集権的なサーバーが
必要というようなバージョン管理システムというのを
Linuxというのはすごい拒絶していました。
その理由というのが、Linuxのような
世界中に開発者が散らばっているようなプロジェクトには
不適合であるというような判断がされていたそうです。
具体的な理由としては、
中央サーバーへのネットワークアクセスが必要になってしまうので
コミットの確認とか、ログの確認というのが
非常に遅くなってしまうという点と、
分解した開発ラインである、今でいうブランチですね。
ブランチの統合する機能というのが
サブバージョンだったりとかいうのは弱くてですね、
コンフリクトしてしまうと解消というのがとても大変
というのがあったり、あとは開発者が
オフラインで作業してローカルで履歴を管理するというような
Linuxカーネル開発における
根幹をなすようなワークフローというのが
サポートできていなかったというところが挙げられています。
Gitの誕生と特徴
そうやってそんなLinuxカーネルの開発なんですけど、
2002年にですね、大きな動きがありました。
BitMover社という
会社のCEOであり、
かつLinuxカーネルの開発にも参加していた
Larry McVoyという方が自社製品である
分散バージョン管理システム、BitKeeperというものを
Linuxコミュニティに対して無償提供するということがありました。
このBitKeeperなんですけど、
2002年当時はですね、画期的でした。
分散型のアーキテクチャを持っていたので、
かなり画期的なツールでした。
リポジトリを完全なコピーをローカルに持って
変更セット単位で履歴を管理できるような形になっていました。
これというのがまさにLinuxが求めていた
そのものだったというようなことがあります。
なのでBitKeeperというのは
Linuxカーネルの開発で採用されるというような形になりました。
これによって実際にですね、
Linuxカーネルの開発速度というのは画期的で向上したそうです。
なんですけど、Linuxコミュニティの中には
このBitKeeperを使うというのは
批判というものも結構あったそうです。
自由なOSであるLinuxを作るためにですね、
不自由な商用ツールを使うというのが
矛盾があったからというのがあったそうです。
また同時にですね、懸念点として無償ライセンスとして
提供されていたんですけど、
そちらの制約条件というものがありました。
そちらがですね、BitKeeperを使用している間というのは
競合するバージョン管理システムの開発をしてはいけない
というような競合開発禁止があります。
さらに利用状況というのは
すべてBitMover社のサーバーによって監視される
というような状況がありました。
そんな中でですね、2002年からBitKeeperというツールを
Linuxカーネルで利用していたんですけど、
2005年にですね、問題が発生します。
そちらがLinuxカーネルの開発者がですね、
BitKeeperのプロトコルを解析して
別のクライアントを開発しようとしてしまったというのがあります。
具体的に言うと、BitKeeperのレポジトリから
メタデータを引き出すというようなツールというのを
開発してしまったというのがあります。
これに対してですね、BitMover社のCEOであるラリー・マクボイさんは
大激怒します。ライセンス違反だと見なされてしまって
Linuxコミュニティ全体に対して
BitKeeperの無償利用権というのを剥奪するというような
形になりました。
これによってLinuxコミュニティ自体はですね、
主要な開発ツールであったBitKeeperというのが突然奪われることになってしまったので
なかなか大変だったというところがあります。
そういった事件があって、BitKeeperという
開発ツールというのを2005年の4月に
Linuxカーネルチームを失うことになるんですけど
そういった状況であったとしてもLinuxはですね
CVSやSVNなどの既存のツールというのは
戻るつもりはなかったそうです。
そこでLinuxどうしたかというと
1週間程度の休みを取ります。
そこで自らの手で理想的なバージョン管理システムを
開発するということを決意します。
これが後のGitとなるものになります。
そして面白いことにGitの設計哲学として
ここでLinuxが決めたことがあります。
それがCVSの逆をやれというものがあります。
CVSを反面教師として
設計に迷ったらCVSがやっていることの
正反対を選べばいいというような分かりやすいところです。
具体的なところでいうと当時のツールがですね
30秒以上かかっていたパッチの適用というのを
3秒以内に完了させるというような
パフォーマンス面の目標を掲げたりとか
あとは中業サーバーを信頼せずにですね
全てのクローンが完全なバックアップとなるような構造にしたりとか
あとはAR階級やデータ発送を
暗号学的ハッシュによって確実に検知できるようにしたり
そういったところを設計の
土台として入れていったというところがあります。
そしてここからLinuxの
怒涛の開発ラッシュというのが始まっていくんですけど
実際に開発開始したのはですね
2005年の4月3日から開発開始したんですけど
ここから2005年の4月6日にはですね
公表をLinuxカーネルのメーディングリストで行います。
そして翌日4月7日にはですね
Gitのソースコード自体をGitで管理できるようになります。
この時点で基本的なコミットとか書き込み読み出し
という機能がほぼほぼ完成したという形になっています。
そして4月18日には
複数ブランチのマージンに成功し
4月29日にはですね
パフォーマンス面での目標を達成することになります。
これによってLinuxカーネルへのパッチ適用速度というのが
毎秒6.7パッチというのを記録できるようになっています。
さらに2005年の6月16日には
Gitによって管理された最初のLinuxカーネル
2.6.12がリリースされるというような形になっています。
こういった形でほぼほぼ数日で
Gitのコア部分というのは
Linux自身で一人で開発されたというような形になっています。
ここでですね、Gitの名前の理由来ですね。
なんでGitという名前なのかというところなんですけど
それについてはLinux自身が説明しているんですが
イギリス英語で不愉快なやつ間抜けといった
意味を持つGitという名前なんですけど
じゃあですね、Linuxは私は自己中心的な人間だから
自分のプロジェクトには自分の名前を付ける
Linuxとかですね。今回もそうだ。
Gitイコール不愉快なやつという形で
自虐的に語っているというところがあります。
なのでGitというのはかっこいい理由というよりかは
悪いような意味として付けられているというようなところがある
というのはなかなか面白いところかなと思いました。
ここでですね、Gitの中身について少しだけ触れていけたらなと思うんですけど
Gitが他のバージョン管理システムと異なっていた
Gitの設計と特徴
というのはVCSバージョンコントロールシステムとして設計されていたのではなくて
コンテンツファイルシステムとして設計されていたというところが
実はあったりします。
こちらはどう違うのかというとですね
従来のバージョン管理システムというのは
基本的にはファイルごとのサブを積み重ねて
履歴を管理していくというような形になっていました。
なんとなくバージョン管理システムを作る際にですね
どうやって作るかなということを考えると
ファイルごとのサブを積み重ねていくというのが
自然な発想かなと思うんですけど
実はGitでは違うというような形になっています。
Gitではどうなっているのかというと
コミットのたびにですね
プロジェクト全体のスナップショットを
すべて保存するというような設計になっています。
その中身、具体的にはすべてのオブジェクトというのは
その内容のシャーワンハッシュによって識別されています。
ファイルの内容が少しでも変わればですね
このハッシュが変わるため
このシャーワンハッシュというのが変わるためですね
それを参照するようなディレクトリ構造を表す
ツリーというオブジェクトもあるんですけど
そちらの方もハッシュで管理されていて
そちらのハッシュも変わります。
さらに関連するコミットのハッシュというのも
すべて変わる。
つまり少しでもファイルの内容を変えてしまえば
すべてのハッシュというのが変わってしまう
という形になります。
これが何を意味するかというと
これによって履歴の回帰というのは
数学的に不可能になっています。
この構造こそがですね
信頼性と分散性というのを支えるような
コア部分になっています。
浜野潤の貢献
さてここからはですね
Gitを現在のように
使いやすいツールへ
どう育ったのかというところを
少しだけ説明していけたらなと思います。
ここにですね
深く関わっているのは
実は日本人のソフトウェアエンジニアの方がおります。
それが浜野潤さんというような方です。
浜野さんはですね
現在Googleに所属するソフトウェアエンジニアの方なんですけど
2005年の7月から現在まで
ずっとGitのメンテナンスを
勤めているような方です。
実はですね
Linuxにとってはですね
Gitというのは
Linux kernelの開発のための
一つの手段でしかなかったので
Gitのメンテナンスというのは
一生続けるつもりはなかったそうです。
なのでGit開発から
わずか数ヶ月後の2005年の7月にですね
開発の手動件というのを
全て浜野さんに移情するという形を
取られました。
なので浜野さんという方が
現在までのGitというのを
ほぼ育てたといっても
確保ではないかなと思うんですが
浜野さんのリードによってですね
2005年の12月には
バージョン1.0がリリースされるような
形になっています。
浜野さんが主に何をしたかというとですね
開発初期のGitというのは
実はサポートしていたコマンドというのがですね
かなり低レベルレイヤーのものしか
ありませんでした。
今使っているようなGit Addだったり
Git Commitみたいないうものは
揃っていませんでした。
それをですね浜野さんは一般開発者でも
使いやすいようなGit Addだったり
Git Commitだったり
というところを整備したというところが
かなりでかいところかなと思います。
これというのが
浜野さんの哲学である
安定性と広報互換性の
重視というところがですね
このGitを現在における
企業ユースに頼るようなツールに
成長させたんじゃないかなと
僕自身は思っております。
GitとGitHubの普及
さて実はですね
先ほどのGitの誕生で
お話ししたビットキーパーの事件ですね。
そちらなんですけど
ビットキーパーの事件というのは実は
Gitだけではなくてですね
マーキュアルという別のバージョン管理システム
というのも生み出していました。
このマーキュアル
というのはビットキーパーの
代替を目指したようなツールで
Pythonで書かれていたんですけど
Gitと比較するとですね
GitはC言語で書かれていたので
拡張性や理解というのがPythonの方が
良いであるとみなされていたそうです。
なのでGitとマーキュアルというのは
なかなか数年間
派遣争いというのをしていたんですけど
結果的にはGitが勝利しました。
その要因としてはですね
リラックスカーネルで利用されていた
というような開発の実績だったり
パフォーマンス面で
マーキュアルよりかGitの方が
早かったというところがあります。
ただ最大の理由ですね
こちらなんですけど
GitHubの登場というものがあります。
こちらのGitHubなんですけど
2008年にGitHubが
ローンチされるんですが
それまではですねGitのレプチトリというのを
ホスティングして他社と共有する
というのはなかなか技術的に
ハードルが高くありました。
そこにGitHubが現れて
Gitの分散機能をサポートする形で
ウェブブラウザから簡単に
操作できるようにしたというところが
かなりでかいところです。
さらにGitにはない概念であった
フォークやプロリクエストというのを
普及させた立役者
でもあります。
これによってコードレビューというのが
爆発的にしやすくなって
結果的にGitの普及率というのが
向上したんじゃないかなと思っております。
ちなみにGitもGitHub上で
レプチトリというのを
持っているんですけど
こちらは実は公式のレプチトリの
ミラーに過ぎないというところが
事実としてあります。
Gitの開発ではどうやっているのかというと
Gitの開発はGitHubを使わずに
GitHubが登場する以前から
メーリストを通じた
パッチの投稿とレビューというような
ワークフローというのを
2025年の現在も維持しているような形になっています。
なのでGitの開発に
貢献したいというような方は
変更内容をパッチ形式のメールとして
メーリングリストに
送信するというような形になっています。
なのでGitの開発
自体ではGitHubの
プルリクエストのような機能というのは
利用されていないというような形になっています。
さてそんな
Gitなんですけど
バージョン1.0のリリースから
20年以上が経過していますが
現在もGitというのは
同等進化をし続けています。
Gitの根幹である
シャアワンによるハッシュアルゴリズムというのがあるんですが
そちら実は
衝突の脆弱性というのが発見されています。
なのでシャア256aの
計画というのは実際には進めているというような
状況になっています。
またマイクロソフトが
Windows自体のWindows OSの
開発をGitに移行するときに
300GBを超える
リポジトリのサイズと
350万個以上のファイル数というところが
移行の壁になってしまったんですけど
これに対してマイクロソフトは
対応するための独自ツールというのを
開発してその知見というのは
Gitの本体にフィードバックして
巨大なリポジトリへの対応というのが
Git自体でも
できるような形になっています。
さらに近年
AIによるコーディングというのが
かなり普及してきているかなと思うんですが
そちらのAIによって
コーディングされる
学習元ですね
それらというのが
Gitによる変更履歴というところが
有用な学習データとして
起動しているというような形になっています。
さてここまで
Gitの歴史についてお話ししてきました。
最後にまとめたいと思います。
Gitはリラックスカーネルの
開発のためにLinuxが
たった数日でコア部分を開発した
ツールになっています。
現在までのGitの復元というのは
Gitを使いやすくして
まとめてくれた浜野さんという方の
功績がかなり大きいです。
さらに未来において
AI時代においてGitによる
変更履歴というのはとても貴重なデータ資産
になっております。
さて今回のお話は
以上となります。もし少しでも
今回の話がいいねと思ったら
お聞きのプラットフォームでの高評価と
フォローの方をお願いします。
またXなどでハッシュタグ
OSSの歴史ラジオで仮想など
つぶやいてもらえると励みになります。
次回は
メタ社が開発した革新的な
フロントエンドフレームワークである
リアクトの歴史について見ていけたらなと思います。
それでは次回も
よろしくお願いします。バイバイ。
