Git （ギット[2] [3] プログラム のソースコード などの変更履歴を記録・追跡するための分散型バージョン管理システム である。Linuxカーネル のソースコード管理に用いるためにリーナス・トーバルズ によって開発され、それ以降ほかの多くのプロジェクトで採用されている。Linuxカーネルのような巨大プロジェクトにも対応できるように、動作速度に重点が置かれている。現在のメンテナは濱野純 (英語 : Junio C Hamano ) で、2005年7月から担当している。
Gitでは、各ユーザのワーキングディレクトリに、全履歴を含んだリポジトリ の完全な複製が作られる。したがって、ネットワーク にアクセスできないなどの理由で中心リポジトリにアクセスできない環境でも、履歴の調査や変更の記録といったほとんどの作業を行うことができる。これが「分散型」と呼ばれる理由である。
背景および概要
Linuxカーネルの開発では、Linux Kernel Mailing List[※ 1] BitKeeper というバージョン管理システムを用いていたが、このソフトウェアは商用ソフトウェア であった（クライアント はバイナリ版のみ無料で、サーバ は商用だがBitMover社の厚意で無料で使えていた）。この状況を快く思わない人々がBitKeeperのクローンを実装したことから、この環境が使えなくなってしまい（BitKeeper#ライセンス問題 やBitKeeper#価格変更 を参照）、その代替として2005年にGitが開発された[4]
Linuxカーネルの開発では、巨大なソースコードの集合を扱うため、変更点の抽出やリポジトリ操作ができるかぎり高速にできる必要がある。他の様々なバージョン管理システムをあたったが、満足のいくものがなかったため、Gitではこのような問題も出来る限り解決できるよう、いくつかのアイデアが導入されている（この部分は、他のバージョン管理システムにも同様の機能が導入されるようになった）。
作業の流れ
Gitは分散型のソースコード管理システムであるため、リモートサーバ等にある中心リポジトリの完全なコピーを手元（ローカル環境）に作成して、そのローカルリポジトリを使って作業を行う。
一般的な開発スタイルでは、大雑把に言えば、以下のようなステップの繰り返しで作業が行なわれる：
リモートサーバ等にある中心リポジトリをローカルに複製する (git clone)。
ローカルでコンテンツの修正・追加・削除を行い、ローカルリポジトリに変更履歴を記録する (git commit)。必要に応じて過去の状態の閲覧や復元などを行う。場合によってはこのステップを何度か繰り返す。
ローカルの変更内容を中心リポジトリに反映させる (git push)。作業者ごとの変更内容が衝突することもある。Gitが自動で解決できる場合もあれば、手動での解決 (git merge）が必要なこともある。
更新された中心リポジトリ（他者の作業内容も統合されている）をローカルの複製にも反映する (git pull)。これによりローカル環境のコードも最新の内容になるので、改めてステップ2の作業を行う。 リポジトリ間の通信 (clone, pull, push) では以下のプロトコルが使用できる[5]
以前はrsync も使用できたが、2.8.0で廃止された[9]
設計
Gitの設計はBitKeeper とMonotoneが元になっている[10] [11] [12] [13]
Gitの設計には、リーナスが大規模プロジェクトのメンテナンスを行った経験や、ファイルシステムのパフォーマンスに関する深い知識、また実用性のあるシステムを短期間に作成しなければならないという差し迫った必要性（BitKeeper を参照）が反映されている。これらの影響は、以下のような形で実装に現れている。
ノンリニアな開発スタイルに対する強力なサポート。Gitではブランチやマージが高速に行える。また、ノンリニアな開発の履歴を可視化・ナビゲートするための専用のツールを同梱している。また、ツリーに対する1回の変更に対して、複数回のマージが発生するという前提を置いているが、これは変更点が複数のレビュアーによってレビューされることを想定しているためである。
分散開発。他の分散型バージョン管理システム（Mercurial 、BitKeeper 、Darcs、Bazaar 、SVK、Monotone）と同様に、Gitでも各々の開発者がリポジトリの完全なコピーをローカルに保持しており、各開発者の行った変更は他のリポジトリにコピーされる。これらの変更は新しい開発用ブランチとしてインポートされる。また、ローカルな開発用ブランチへのマージも可能である。
HTTP 、FTP 、gitプロトコル（ssh を利用したトンネリングも可能）を使用したリポジトリの配布が可能。また、CVS サーバのエミュレーション機能を使用すれば、既存のCVSクライアントやIDEのプラグインからGitリポジトリにアクセスできる。git-svnを使用すれば、Subversion およびsvkのリポジトリを直接操作できる。
大きなプロジェクトにおける処理の効率化。Gitは非常に高速かつスケーラブルになるよう記述されている[14] Mozilla によって行われたパフォーマンステストでは、他のリビジョンコントロールシステムと比較して10倍、処理によっては100倍高速に動作することが示された[15] [16]
ツールキット化された設計。gitはC言語 で書かれたプログラム一式と、それらのラッパーとなる何本かのシェルスクリプト で構成されている[17] [18]
プラガブルなマージアルゴリズム。Gitでは不完全なマージに対する優れたモデル化が行われている。また、不完全なマージを補完するアルゴリズムも複数存在する。最終的に自動的なマージが行えなかった場合には、ユーザによる編集が必要である旨がユーザに通知される。
ガベージコレクション は行われない。操作を中断したり変更の取り消しを行った場合、データベース中には不要なデータが残ったままになる。これらのデータは操作対象のオブジェクトの履歴に比例して大きくなる。git-gc --pruneコマンドを使用して明示的にガベージコレクションを行うこともできるが、この処理には時間がかかる[19] Gitの特徴の一つとして、ディレクトリツリーに対するスナップショットを作成する点が挙げられる。初期のバージョン管理システム（SCCS やRCS ）では、個々のファイルを処理の対象としており、直近のバージョンに対して差分符号化 を行うことでリポジトリのサイズを縮小することに機能の重点が置かれていた。以降のバージョン管理システムでも、この「プロジェクト内の複数バージョンにまたがって一つのファイルを追跡できる」という概念が継承されていた。
一方、Gitではこのコンセプトを使用していない[20]
プロジェクト全体の変更履歴を調べるよりも、一つのファイルの変更履歴を調べる方が時間がかかる[21]
ファイル名の変更を明示的に扱わない。CVSに対してよく挙げられる不満として、ファイルのリネームや移動を行うと変更履歴が途切れてしまう問題がある。これは、変更履歴の識別にファイル名を使用しているためである。CVS以降に開発されたバージョン管理システムの多くでは、管理対象のファイルに対してファイル名より寿命の長い、内部的な名前（inode番号 のようなもの）を付与することでこの問題を解決している。一方、Gitではそのような内部名を使用しておらず、その点が長所であるとしている[22] [23] ソースコード に対しては、リネームの他にも分割やマージといった処理が行われる[24] [25] CPU に負荷のかかる処理が必要となる。そのため、使用するヒューリスティックを選択するオプションが提供されている。 リポジトリの保存方法については批判もある。
Gitは新しく作成されたオブジェクトを個別のファイルの形で保存する。各ファイルは圧縮されて保存されるが、そうであったとしてもこの方法は記録領域を大量に必要とするため非効率的である。Gitはこの問題を“pack”を使用することで解決している。複数のオブジェクトは一つのファイル（またはネットワークバイトストリーム）の形にパックされ、各pack間で差分圧縮が行われる。packの差分圧縮にはヒューリスティック が用いられる。例えば、同じ名前のファイルは似た内容である可能性が高いものとして処理される。ただし、リポジトリの正確性を保つため、ヒューリスティックに完全に依存することはない。現在のGitでも新しく作成されたオブジェクト（新しく加えられた履歴）はまず単一のファイルとして保存されるため、空間効率を高く保つためには定期的な再パックが要求される。Gitはこの定期的な再パックを自動的に行うが、git gcコマンドを使用することで手動で再パックを行うこともできる。 Gitは以下のマージアルゴリズムを実装している。アルゴリズムはマージ時に選択することができる[26]
resolve
従来通りの3-wayマージアルゴリズムを使用する。
recursive
3-wayマージの変種を使用する。ブランチのmergeやpullを行う場合のデフォルトである。3-wayマージにおいて共通の祖先が複数ある場合、共通の祖先からのmerge treeを作成し、それをreference treeとして3-wayマージを行う。Linuxカーネル2.6の開発で行われたマージコミットの履歴から、このアルゴリズムを使用するとマージの衝突が少なく、マージ漏れもなかったことが報告されている。さらに、リネームを伴うマージに対しても検出および処理が可能である[27]
octopus
3つ以上のheadからのマージを行う場合のデフォルトである。
歴史
名前の由来
リーナス・トーバルズによれば[28]
「
僕は自己中心的な奴だから、自分のプロジェクトには自分にちなんだ名前を付けるようにしているんだ。最初はLinux で、今度はGitだ。
」
英語のスラングとして、Gitには「バカ」「間抜け」といった類の意味がある。この自虐ネタはもちろん皮肉で、これはリーナスがLinuxの名前を決める際に自身の名前にちなんだ名前を付けるよう強要されたことから来ている。(Linux#名前の由来 を参照)
Gitのオフィシャルサイトのウィキ では、“Git”という名前に対して他にもいくつかの解釈がなされている。例としてはGlobal Information Tracker などが挙げられる[29]
開発初期の歴史
Gitの開発は、Linuxカーネルの開発者の多くがBitKeeperのシステムに対するアクセスを禁止されたことに端を発している（BitKeeper#価格変更 を参照）。これは、アンドリュー・トリジェル (Andrew Tridgell) がプロプラエタリなソフトウェアであるBitKeeperのプロトコルをリバースエンジニアリング したことに対し、BitKeeperの著作者であるラリー・マクボイ がこれをライセンス違反であるとして、BitKeeperの無料提供を止めたためである。Linux.conf.au 2005のキーノートにおいて、トリジェルはこのリバースエンジニアリングの手順について説明を行ったが、内容はBitKeeperのサーバの適切なポートにtelnet でアクセスし“help”とタイプするだけという単純なものだった[30]
リーナスはBitKeeperと同じように使える分散型バージョン管理システムを探していたが、無料のシステムで彼の要求（特に速度面での要求）に適合するものは見つからなかった。リーナスが書いたメールによると、2005年4月7日頃に最初のプロトタイプ を作成していたようである[31]
「
だけど、僕が見たSCM たちはそれ（bk pull 相当のこと）をするのが大変だったんだ。僕がやろうとしていることの1つは（実はこれが一番なんだけど）その過程を十分効率的 にすること。もし1つのパッチを適用してその変更の境界を記録するなどするのに30秒かかったとすると（正直、Linux規模のプロジェクトで30秒っていうのは大抵のSCMでは速いほうの見積りだけど）、250通（例えばAndrew[※ 2]
BKはスピード狂ではなくて、（他のSCMと比較するとBKは1桁か2桁くらいは高速だけど）Andrew[※ 2] 速く しなければならなくなる。それは本当に本当に大変なこと。
だから、僕はいまスクリプトを書いていて、変更をずっと速く追跡できるようにしているんだ。最初の目標はパッチを適用するのと同じくらい高速にそれを行うこと。だけどはっきりいって、今のところできたのは多く見積もってもまだ半分くらいで、思わぬ障害にぶつかったら全然嘘になるかもしれないけど。いずれにせよ、僕がそれをすぐにできる理由は、僕のスクリプトがSCMではないからで、とても特別で "Linuxの状態を記録する" ようなものだからなんだ。それはリニアなパッチを十分効率的な時間でマージできるようになるだろう。
（パッチの適用が3秒でできるなら、大きな1つながりのパッチでも問題にはならない: 途中で失敗しても1分か2分で気がつくなら、それで十分で、手作業で修正することができる。待ち時間が重要な理由はそこにある。-- "オフライン" で効果的にそれができるなら、問題が起きた時に僕は定義どおりそれを修理できずにいるだろう）
」
リーナスは以下のような原則に基づいて設計を行っている。
CVS を「悪い見本」とする。設計上のことで確信が持てない場合は、CVSと逆の決断をする。リーナスは冗談めかして以下のように語っている。
“カーネルメンテナンスの最初の10年間、僕らは文字通りtarボールとパッチを使っていた。CVSよりもずっと優れたソース管理システムさ。僕は営利企業（トランスメタ [32] Subversion ) のユーザがいるなら、この場から去ったほうがいいかもしれない。僕がCVSを強烈に嫌悪しているということは、僕がSubversionが史上最大の無意味なプロジェクトであると思っていることも意味しているんだ。Subversionのしばらくのスローガンは‘ちゃんとCVSをやる’とかそんなものだったよね。そんなスローガンから始めたら、どこにも辿りつけないよ。CVSをちゃんとやるなんて不可能なのさ。”[33] 分散型の、BitKeeperのようなワークフローをサポートする。
“BitKeeperだけが、「まあ使ってもいいかな」と最初に思わせてくれたSCMだというわけではないけれど、BitkeeperはSCMというものの存在意義と、実際にどう使うことができるのかを教えてくれた。だから、Gitは技術的な観点とかいろんなところでBitkeeperとは随分違うものになっているけど（それはもう一つの設計目標でもある。Bitkeeperのクローンではないことをはっきりさせたかったから）、Gitのワークフローの多くは、Bitkeeperが教えてくれたフローから直接きたものになっているんだ。”[33]
データ破壊に対する強力な抑止機能。データ破壊は、偶然によるものと意図的なものの両方を想定している[34] [33]
非常に高い処理速度。 最初の3つの条件によって、既存のバージョン管理システムはMonotoneを除き全て選に漏れてしまい、4つ目の条件で該当するものがなくなってしまった[33] [33] [33]
Gitの開発は2005年4月3日に開始された[35] [36] セルフホスティング されるようになった[35] [37] [38] [39]
BitKeeperからの影響で、リーナスは従来と同じようなアプローチを意図的に避けており、結果としてGitは非常にユニークな設計になっている[40] 濱野純 (Junio C Hamano) にメンテナンスが引き継がれた[41] [42]
ブランチモデル
ソフトウェア開発におけるGitブランチの作成・更新モデルをブランチモデル と呼ぶ。
GitHub flow
GitHub flowはブランチモデルの一種である[43] masterブランチは常にデプロイ可能」である[44] masterからforkする。マージ時を含め他者からの意見募集・レビューを行う際にはpull request（merge request）を用いる。pull request時に自動化テスト（c.f. 継続的インテグレーション ）をおこなうことでmergeの安全性を確保し、masterが常に正常 = デプロイ可能に保たれる。GitHub flowが有効な分野は継続的デリバリー ・継続的デプロイメント が有効な分野、例えばWebサービスが挙げられる。
2011年の提唱時と比較して、GitHub社ではモデルの一部を変更している。オリジナルのGitHub flowでは更新がmasterへマージされ、そこからデプロイされる。GitHub社ではレビュー後（CI後）のtopic branchが最終テストとしてプロダクション環境へデプロイされる。そこで問題がないと確認されたのちにmasterへmergeされている[45] masterのrevert commitではなくmasterの再デプロイで対応できる。
マージ
Gitはブランチのマージ （merge）に対応している。
マージが行われるとマージコミット （英: merge commit）が生成される。コンフリクトが発生しない場合、git merge [46] [47] [48] git addをおこない、git commitあるいはgit merge --continueをおこなってはじめてマージコミットが生成される[49]
マージコミットの実体は2つ以上のparent属性を持つただのコミットオブジェクトである（特別なGitオブジェクトではない）[50]
- 2024年5月31日 [±]
