開発初期の歴史

ウィキペディア小見出し辞書

開発初期の歴史

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2017/05/08 07:41 UTC 版)

「git」の記事における「開発初期の歴史」の解説

gitの開発は、Linuxカーネルの開発者の多くがBitKeeperのシステムに対するアクセスを禁止されたことに端を発している（BitKeeper#価格変更を参照）。これは、アンドリュー・トリジェル(Andrew Tridgell)がプロプラエタリなソフトウェアであるBitKeeperのプロトコルをリバースエンジニアリングしたことに対し、BitKeeperの著作者であるLarry McVoy(en)がこれをライセンス違反であるとして、BitKeeperの無料提供を止めたためである。Linux.conf.au 2005のキーノートにおいて、Tridgellはこのリバースエンジニアリングの手順について説明を行ったが、内容はBitKeeperのサーバの適切なポートにtelnetでアクセスし“help”とタイプするだけという単純なものだった。 リーナスはBitKeeperと同じように使える分散型バージョン管理システムを探していたが、無料のシステムで彼の要求（特に速度面での要求）に適合するものは見つからなかった。リーナスが書いたメールによると、2005年4月7日頃に最初のプロトタイプを作成していたようである。 “ だけど、僕が見たSCMたちはそれ（bk pull相当のこと）をするのが大変だったんだ。僕がやろうとしていることの1つは（実はこれが一番なんだけど）その過程を十分効率的にすること。もし1つのパッチを適用してその変更の境界を記録するなどするのに30秒かかったとすると（正直、Linux規模のプロジェクトで30秒っていうのは大抵のSCMでは速いほうの見積りだけど）、250通（例えばAndrew と同期するときには決して珍しい量じゃない）のメールパッチを適用するのに2時間かかることになる。 BKはスピード狂ではなくて、(他のSCMと比較するとBKは1桁か2桁くらいは高速だけど）Andrewとマージをする時に1メールにつき約10-15秒かかっていた。だけど、BKではそれは大きな問題にならなかったんだ。BK<->BK間のマージは簡単だから、僕は他の主要な開発者とは時間がかかるメールでのマージをしたことはなかったから。パッチアプリケーションに基づいたSCMにするなら、“マージ機能”をBKよりも速くしなければならなくなる。それは本当に本当に大変なこと。 だから、僕はいまスクリプトを書いていて、変更をずっと速く追跡できるようにしているんだ。最初の目標はパッチを適用するのと同じくらい高速にそれを行うこと。だけどはっきりいって、今のところできたのは多く見積もってもまだ半分くらいで、思わぬ障害にぶつかったら全然嘘になるかもしれないけど。いずれにせよ、僕がそれをすぐにできる理由は、僕のスクリプトがSCMではないからで、とても特別で“Linuxの状態を記録する”ようなものだからなんだ。それはリニアなパッチを十分効率的な時間でマージできるようになるだろう。 （パッチの適用が3秒でできるなら、大きな1つながりのパッチでも問題にはならない: 途中で失敗しても1分か2分で気がつくなら、それで十分で、手作業で修正することができる。待ち時間が重要な理由はそこにある。--“オフライン”で効果的にそれができるなら、問題が起きた時に僕は定義どおりそれを修理できずにいるだろう） ” リーナスは以下のような原則に基づいて設計を行っている。 CVSを「悪い見本」とする。設計上のことで確信が持てない場合は、CVSと逆の決断をする。リーナスは冗談めかして以下のように語っている。“カーネルメンテナンスの最初の10年間、僕らは文字通りtarボールとパッチを使っていた。CVSよりもずっと優れたソース管理システムさ。僕は営利企業 (トランスメタ) でCVSを7年間使わされたことで、CVSを強烈に憎むようになった。CVSを強烈に憎んでいると言う時には、このことも言っておかなくちゃいけないね。観衆の中にSVN（Subversion）のユーザがいるなら、この場から去ったほうがいいかもしれない。僕がCVSを強烈に嫌悪しているということは、僕がSubversionが史上最大の無意味なプロジェクトであると思っていることも意味しているんだ。Subversionのしばらくのスローガンは‘ちゃんとCVSをやる’とかそんなものだったよね。そんなスローガンから始めたら、どこにも辿りつけないよ。CVSをちゃんとやるなんて不可能なのさ。” 分散型の、BitKeeperのようなワークフローをサポートする。“BitKeeperだけが、「まあ使ってもいいかな」と最初に思わせてくれたSCMだというわけではないけれど、BitkeeperはSCMというものの存在意義と、実際にどう使うことができるのかを教えてくれた。だから、gitは技術的な観点とかいろんなところでBitkeeperとは随分違うものになっているけど(それはもう一つの設計目標でもある。Bitkeeperのクローンではないことをはっきりさせたかったから。)、gitのワークフローの多くは、Bitkeeperが教えてくれたフローから直接きたものになっているんだ。” データ破壊に対する強力な抑止機能。データ破壊は、偶然によるものと意図的なものの両方を想定している。 非常に高い処理速度。 最初の3つの条件によって、既存のバージョン管理システムはMonotoneを除き全て選に漏れてしまい、4つ目の条件で該当するものがなくなってしまった。そのため、Linuxカーネル2.6.12-rc2のリリース直後に、リーナスは自分で開発を始めた。 gitの開発は2005年4月3日に開始された。プロジェクトとしてのアナウンスは4月6日に行われ、4月7日にはセルフホスティングされるようになった。4月18日には複数のブランチからのマージが最初に行われた。4月29日にはリーナスの目標としていた処理速度が実現された。Linuxのカーネルツリーにパッチを当てるベンチマークで、初期のgitでは毎秒6.7個のパッチを処理している。6月6日には、gitによるLinuxカーネル2.6.12のリリースが行われた。 BitKeeperからの影響で、リーナスは従来と同じようなアプローチを意図的に避けており、結果としてgitは非常にユニークな設計になっている。技術に長けたユーザがgitを利用できるようになるレベルまではリーナスが開発を行っており、その後、2005年6月26日にはプロジェクトへの主要な貢献者であったJunio C Hamanoにメンテナンスが引き継がれた。Hamanoは2005年12月21日にバージョン1.0のリリースを行い、2009年3月現在も彼がメンテナンスを行っている。

開発初期の歴史

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/08/18 01:06 UTC 版)

「Git」の記事における「開発初期の歴史」の解説

Gitの開発は、Linuxカーネルの開発者の多くがBitKeeperのシステムに対するアクセスを禁止されたことに端を発している（BitKeeper#価格変更を参照）。これは、アンドリュー・トリジェル (Andrew Tridgell) がプロプラエタリなソフトウェアであるBitKeeperのプロトコルをリバースエンジニアリングしたことに対し、BitKeeperの著作者であるラリー・マクボイがこれをライセンス違反であるとして、BitKeeperの無料提供を止めたためである。Linux.conf.au 2005のキーノートにおいて、トリジェルはこのリバースエンジニアリングの手順について説明を行ったが、内容はBitKeeperのサーバの適切なポートにtelnetでアクセスし“help”とタイプするだけという単純なものだった。 リーナスはBitKeeperと同じように使える分散型バージョン管理システムを探していたが、無料のシステムで彼の要求（特に速度面での要求）に適合するものは見つからなかった。リーナスが書いたメールによると、2005年4月7日頃に最初のプロトタイプを作成していたようである。 「 だけど、僕が見たSCMたちはそれ（bk pull相当のこと）をするのが大変だったんだ。僕がやろうとしていることの1つは（実はこれが一番なんだけど）その過程を十分効率的にすること。もし1つのパッチを適用してその変更の境界を記録するなどするのに30秒かかったとすると（正直、Linux規模のプロジェクトで30秒っていうのは大抵のSCMでは速いほうの見積りだけど）、250通（例えばAndrew と同期するときには決して珍しい量じゃない）のメールパッチを適用するのに2時間かかることになる。 BKはスピード狂ではなくて、（他のSCMと比較するとBKは1桁か2桁くらいは高速だけど）Andrewとマージをする時に1メールにつき約10-15秒かかっていた。だけど、BKではそれは大きな問題にならなかったんだ。BK⇔BK間のマージは簡単だから、僕は他の主要な開発者とは時間がかかるメールでのマージをしたことはなかったから。パッチアプリケーションに基づいたSCMにするなら、"マージ機能" をBKよりも速くしなければならなくなる。それは本当に本当に大変なこと。 だから、僕はいまスクリプトを書いていて、変更をずっと速く追跡できるようにしているんだ。最初の目標はパッチを適用するのと同じくらい高速にそれを行うこと。だけどはっきりいって、今のところできたのは多く見積もってもまだ半分くらいで、思わぬ障害にぶつかったら全然嘘になるかもしれないけど。いずれにせよ、僕がそれをすぐにできる理由は、僕のスクリプトがSCMではないからで、とても特別で "Linuxの状態を記録する" ようなものだからなんだ。それはリニアなパッチを十分効率的な時間でマージできるようになるだろう。 （パッチの適用が3秒でできるなら、大きな1つながりのパッチでも問題にはならない: 途中で失敗しても1分か2分で気がつくなら、それで十分で、手作業で修正することができる。待ち時間が重要な理由はそこにある。-- "オフライン" で効果的にそれができるなら、問題が起きた時に僕は定義どおりそれを修理できずにいるだろう） 」 リーナスは以下のような原則に基づいて設計を行っている。 CVSを「悪い見本」とする。設計上のことで確信が持てない場合は、CVSと逆の決断をする。リーナスは冗談めかして以下のように語っている。“カーネルメンテナンスの最初の10年間、僕らは文字通りtarボールとパッチを使っていた。CVSよりもずっと優れたソース管理システムさ。僕は営利企業（トランスメタ）でCVSを7年間使わされたことで、CVSを強烈に憎むようになった。CVSを強烈に憎んでいると言う時には、このことも言っておかなくちゃいけないね。観衆の中にSVN (Subversion) のユーザがいるなら、この場から去ったほうがいいかもしれない。僕がCVSを強烈に嫌悪しているということは、僕がSubversionが史上最大の無意味なプロジェクトであると思っていることも意味しているんだ。Subversionのしばらくのスローガンは‘ちゃんとCVSをやる’とかそんなものだったよね。そんなスローガンから始めたら、どこにも辿りつけないよ。CVSをちゃんとやるなんて不可能なのさ。” 分散型の、BitKeeperのようなワークフローをサポートする。“BitKeeperだけが、「まあ使ってもいいかな」と最初に思わせてくれたSCMだというわけではないけれど、BitkeeperはSCMというものの存在意義と、実際にどう使うことができるのかを教えてくれた。だから、Gitは技術的な観点とかいろんなところでBitkeeperとは随分違うものになっているけど（それはもう一つの設計目標でもある。Bitkeeperのクローンではないことをはっきりさせたかったから）、Gitのワークフローの多くは、Bitkeeperが教えてくれたフローから直接きたものになっているんだ。” データ破壊に対する強力な抑止機能。データ破壊は、偶然によるものと意図的なものの両方を想定している。 非常に高い処理速度。 最初の3つの条件によって、既存のバージョン管理システムはMonotoneを除き全て選に漏れてしまい、4つ目の条件で該当するものがなくなってしまった。そのため、Linuxカーネル2.6.12-rc2のリリース直後に、リーナスは自分で開発を始めた。 Gitの開発は2005年4月3日に開始された。プロジェクトとしてのアナウンスは4月6日に行われ、4月7日にはセルフホスティングされるようになった。4月18日には複数のブランチからのマージが最初に行われた。4月29日にはリーナスの目標としていた処理速度が実現された。Linuxのカーネルツリーにパッチを当てるベンチマークで、初期のGitでは毎秒6.7個のパッチを処理している。6月6日には、GitによるLinuxカーネル2.6.12のリリースが行われた。 BitKeeperからの影響で、リーナスは従来と同じようなアプローチを意図的に避けており、結果としてGitは非常にユニークな設計になっている。技術に長けたユーザがGitを利用できるようになるレベルまではリーナスが開発を行っており、その後、2005年6月26日にはプロジェクトへの主要な貢献者であった濱野純 (Junio C Hamano) にメンテナンスが引き継がれた。濱野は2005年12月21日にバージョン1.0のリリースを行い、2021年5月現在も彼がメンテナンスを行っている。