Git

Git

GitのWebインターフェース、gitweb
開発元かいはつもと	濱野はまの純じゅん, リーナス・トーバルズ, ほか多数たすう
初版しょはん	2005年ねん12月21日にち (2005-12-21)
最新さいしん版ばん	2.46.0  - 2024年ねん7月がつ29日にち [±]
リポジトリ	git.kernel.org/pub/scm/git/git.git
プログラミング 言語げんご	C, Bourne Shell, Tcl, Perl
対応たいおうOS	Unix系けい、Linux、Windows、macOS
種別しゅべつ	バージョン管理かんりソフトウェア
ライセンス	GNU General Public License バージョン2,GNU Lesser General Public License 2.1
公式こうしきサイト	git-scm.com

Git（ギット）は、プログラムのソースコードなどの変更へんこう履歴りれきを記録きろく・追跡ついせきするための分散ぶんさん型がたバージョン管理かんりシステムである。Linuxカーネルのソースコード管理かんりに用もちいるためにリーナス・トーバルズによって開発かいはつされ、それ以降いこうほかの多おおくのプロジェクトで採用さいようされている。Linuxカーネルのような巨きょ大だいプロジェクトにも対応たいおうできるように、動作どうさ速度そくどに重点じゅうてんが置おかれている。現在げんざいのメンテナは濱野はまの純じゅん (英語えいご: Junio C Hamano) で、2005年ねん7月がつから担当たんとうしている。

Gitでは、各かくユーザのワーキングディレクトリに、全ぜん履歴りれきを含ふくんだリポジトリの完全かんぜんな複製ふくせいが作つくられる。したがって、ネットワークにアクセスできないなどの理由りゆうで中心ちゅうしんリポジトリにアクセスできない環境かんきょうでも、履歴りれきの調査ちょうさや変更へんこうの記録きろくといったほとんどの作業さぎょうを行おこなうことができる。これが「分散ぶんさん型がた」と呼よばれる理由りゆうである。

背景はいけいおよび概要がいよう

Linuxカーネルの開発かいはつでは、Linux Kernel Mailing List に投稿とうこうされる多数たすうのパッチをメンテナーたちがソースコードに適用てきようするという形式けいしきが採用さいようされている。これらの作業さぎょうを効率こうりつ的てきに行おこなうため、当初とうしょはBitKeeperというバージョン管理かんりシステムを用もちいていたが、このソフトウェアは商用しょうようソフトウェアであった（クライアントはバイナリ版ばんのみ無料むりょうで、サーバは商用しょうようだがBitMover社しゃの厚意こういで無料むりょうで使つかえていた）。この状況じょうきょうを快こころよく思おもわない人々ひとびとがBitKeeperのクローンを実装じっそうしたことから、この環境かんきょうが使つかえなくなってしまい（BitKeeper#ライセンス問題もんだいやBitKeeper#価格かかく変更へんこうを参照さんしょう）、その代替だいたいとして2005年ねんにGitが開発かいはつされた。

Linuxカーネルの開発かいはつでは、巨大きょだいなソースコードの集合しゅうごうを扱あつかうため、変更へんこう点てんの抽出ちゅうしゅつやリポジトリ操作そうさができるかぎり高速こうそくにできる必要ひつようがある。他たの様々さまざまなバージョン管理かんりシステムをあたったが、満足まんぞくのいくものがなかったため、Gitではこのような問題もんだいも出来できる限かぎり解決かいけつできるよう、いくつかのアイデアが導入どうにゅうされている（この部分ぶぶんは、他たのバージョン管理かんりシステムにも同様どうようの機能きのうが導入どうにゅうされるようになった）。

作業さぎょうの流ながれ

Gitは分散ぶんさん型がたのソースコード管理かんりシステムであるため、リモートサーバ等とうにある中心ちゅうしんリポジトリの完全かんぜんなコピーを手元てもと（ローカル環境かんきょう）に作成さくせいして、そのローカルリポジトリを使つかって作業さぎょうを行おこなう。

一般いっぱん的てきな開発かいはつスタイルでは、大雑把おおざっぱに言いえば、以下いかのようなステップの繰くり返かえしで作業さぎょうが行おこなわれる：

1. リモートサーバ等とうにある中心ちゅうしんリポジトリをローカルに複製ふくせいする (git clone)。
2. ローカルでコンテンツの修正しゅうせい・追加ついか・削除さくじょを行おこない、ローカルリポジトリに変更へんこう履歴りれきを記録きろくする (git commit)。必要ひつように応おうじて過去かこの状態じょうたいの閲覧えつらんや復元ふくげんなどを行おこなう。場合ばあいによってはこのステップを何なん度どか繰くり返かえす。
3. ローカルの変更へんこう内容ないようを中心ちゅうしんリポジトリに反映はんえいさせる (git push)。作業さぎょう者しゃごとの変更へんこう内容ないようが衝突しょうとつすることもある。Gitが自動じどうで解決かいけつできる場合ばあいもあれば、手動しゅどうでの解決かいけつ (git merge）が必要ひつようなこともある。
4. 更新こうしんされた中心ちゅうしんリポジトリ（他者たしゃの作業さぎょう内容ないようも統合とうごうされている）をローカルの複製ふくせいにも反映はんえいする (git pull)。これによりローカル環境かんきょうのコードも最新さいしんの内容ないようになるので、改あらためてステップ2の作業さぎょうを行おこなう。

リポジトリ間あいだの通信つうしん (clone, pull, push) では以下いかのプロトコルが使用しようできる。

• ローカルファイルシステム
• SSH
• git（認証にんしょう機能きのうなし）
• HTTP/HTTPS
  • pushするためには、サーバー側がわにgit-http-backendプログラムまたはWebDAVが必要ひつよう。
• FTP/FTPS: ただし、もはや使つかうべきではないとされている。

以前いぜんはrsyncも使用しようできたが、2.8.0で廃止はいしされた。

設計せっけい

Gitの設計せっけいはBitKeeperとMonotoneが元もとになっている。元々もともとのGitはローレベルなエンジンとして設計せっけいされていたが、これは、他たの開発かいはつ者しゃがCogitoやStGITのようなフロントエンドを容易よういに開発かいはつできるようにすることを目的もくてきとしていた。現在げんざいでは、Gitのコア自体じたいもユーザから直接ちょくせつ利用りようできるようになっている。

Gitの設計せっけいには、リーナスが大だい規模きぼプロジェクトのメンテナンスを行おこなった経験けいけんや、ファイルシステムのパフォーマンスに関かんする深ふかい知識ちしき、また実用じつよう性せいのあるシステムを短期間たんきかんに作成さくせいしなければならないという差さし迫せまった必要ひつよう性せい（BitKeeperを参照さんしょう）が反映はんえいされている。これらの影響えいきょうは、以下いかのような形かたちで実装じっそうに現あらわれている。

• ノンリニアな開発かいはつスタイルに対たいする強力きょうりょくなサポート。Gitではブランチやマージが高速こうそくに行おこなえる。また、ノンリニアな開発かいはつの履歴りれきを可視かし化か・ナビゲートするための専用せんようのツールを同どう梱こりしている。また、ツリーに対たいする1回かいの変更へんこうに対たいして、複ふく数すう回かいのマージが発生はっせいするという前提ぜんていを置おいているが、これは変更へんこう点てんが複数ふくすうのレビュアーによってレビューされることを想定そうていしているためである。
• 分散ぶんさん開発かいはつ。他たの分散ぶんさん型がたバージョン管理かんりシステム（Mercurial、BitKeeper、Darcs、Bazaar、SVK、Monotone）と同様どうように、Gitでも各々おのおのの開発かいはつ者しゃがリポジトリの完全かんぜんなコピーをローカルに保持ほじしており、各かく開発かいはつ者しゃの行おこなった変更へんこうは他たのリポジトリにコピーされる。これらの変更へんこうは新あたらしい開発かいはつ用ようブランチとしてインポートされる。また、ローカルな開発かいはつ用ようブランチへのマージも可能かのうである。
• HTTP、FTP、gitプロトコル（sshを利用りようしたトンネリングも可能かのう）を使用しようしたリポジトリの配布はいふが可能かのう。また、CVSサーバのエミュレーション機能きのうを使用しようすれば、既存きそんのCVSクライアントやIDEのプラグインからGitリポジトリにアクセスできる。
• git-svnを使用しようすれば、Subversionおよびsvkのリポジトリを直接ちょくせつ操作そうさできる。
• 大おおきなプロジェクトにおける処理しょりの効率こうりつ化か。Gitは非常ひじょうに高速こうそくかつスケーラブルになるよう記述きじゅつされている。Mozillaによって行おこなわれたパフォーマンステストでは、他たのリビジョンコントロールシステムと比較ひかくして10倍ばい、処理しょりによっては100倍ばい高速こうそくに動作どうさすることが示しめされた。
• ツールキット化かされた設計せっけい。gitはC言語げんごで書かかれたプログラム一式いっしきと、それらのラッパーとなる何なん本ほんかのシェルスクリプトで構成こうせいされている。GitをWindowsに移植いしょくする過程かていで、シェルスクリプトのほとんどはC言語げんごで書かき直なおされた。しかし、現在げんざいでも複数ふくすうのコンポーネントを繋つなげることで複雑ふくざつな処理しょりを容易よういに行おこなえるような設計せっけいになっている。
• プラガブルなマージアルゴリズム。Gitでは不完全ふかんぜんなマージに対たいする優すぐれたモデル化かが行おこなわれている。また、不完全ふかんぜんなマージを補完ほかんするアルゴリズムも複数ふくすう存在そんざいする。最終さいしゅう的てきに自動的じどうてきなマージが行おこなえなかった場合ばあいには、ユーザによる編集へんしゅうが必要ひつようである旨むねがユーザに通知つうちされる。
• ガベージコレクションは行おこなわれない。操作そうさを中断ちゅうだんしたり変更へんこうの取とり消けしを行おこなった場合ばあい、データベース中ちゅうには不要ふようなデータが残のこったままになる。これらのデータは操作そうさ対象たいしょうのオブジェクトの履歴りれきに比例ひれいして大おおきくなる。git-gc --pruneコマンドを使用しようして明示めいじ的てきにガベージコレクションを行おこなうこともできるが、この処理しょりには時間じかんがかかる。

Gitの特徴とくちょうの一ひとつとして、ディレクトリツリーに対たいするスナップショットを作成さくせいする点てんが挙あげられる。初期しょきのバージョン管理かんりシステム（SCCSやRCS）では、個々ここのファイルを処理しょりの対象たいしょうとしており、直近ちょっきんのバージョンに対たいして差分さぶん符号ふごう化かを行おこなうことでリポジトリのサイズを縮小しゅくしょうすることに機能きのうの重点じゅうてんが置おかれていた。以降いこうのバージョン管理かんりシステムでも、この「プロジェクト内ないの複数ふくすうバージョンにまたがって一ひとつのファイルを追跡ついせきできる」という概念がいねんが継承けいしょうされていた。

一方いっぽう、Gitではこのコンセプトを使用しようしていない。その結果けっかとして、Gitはソースコードツリー中ちゅうのファイルのリビジョン間あいだの関係かんけい性せいを記録きろくしなくなっている。これにより、Gitは以下いかのような特徴とくちょうをもつようになっている。

• プロジェクト全体ぜんたいの変更へんこう履歴りれきを調しらべるよりも、一ひとつのファイルの変更へんこう履歴りれきを調しらべる方ほうが時間じかんがかかる。特定とくていのファイルの変更へんこう履歴りれきを取得しゅとくする場合ばあい、Gitはツリーの履歴りれき全体ぜんたいを走査そうさし、各かくリビジョンでそのファイルに変更へんこうがあったかどうか調査ちょうさする必要ひつようがある。ただしこの処理しょり手順てじゅんでは、一ひとつのファイルに対たいしても、任意にんいのファイルの集合しゅうごうに対たいしても、ほぼ同おなじ時間じかんで履歴りれきの調査ちょうさが行おこなえる。よく行おこなわれる処理しょりとしては、例たとえば「ソースツリー中ちゅうのあるサブディレクトリと、それに関係かんけいするヘッダファイルの調査ちょうさを行おこなう」といったものがある。
• ファイル名めいの変更へんこうを明示めいじ的てきに扱あつかわない。CVSに対たいしてよく挙あげられる不満ふまんとして、ファイルのリネームや移動いどうを行おこなうと変更へんこう履歴りれきが途切とぎれてしまう問題もんだいがある。これは、変更へんこう履歴りれきの識別しきべつにファイル名めいを使用しようしているためである。CVS以降いこうに開発かいはつされたバージョン管理かんりシステムの多おおくでは、管理かんり対象たいしょうのファイルに対たいしてファイル名めいより寿命じゅみょうの長ながい、内部ないぶ的てきな名前なまえ（inode番号ばんごうのようなもの）を付与ふよすることでこの問題もんだいを解決かいけつしている。一方いっぽう、Gitではそのような内部ないぶ名めいを使用しようしておらず、その点てんが長所ちょうしょであるとしている。プログラムのソースコードに対たいしては、リネームの他ほかにも分割ぶんかつやマージといった処理しょりが行おこなわれる。これらの処理しょりを単純たんじゅんにファイルのリネームとして十把一絡じっぱひとからげに扱あつかうと、実際じっさいにソースコードツリーに対たいして行おこなわれた処理しょりが何なにであるか不明瞭ふめいりょうなまま履歴りれきに記録きろくされてしまう。Gitでは、リネームの検出けんしゅつをスナップショット作成さくせい時じではなく履歴りれきのブラウズの際さいに行おこなうことでこの問題もんだいを解決かいけつしている。（単純たんじゅんに考かんがえれば、リビジョンN中なかのあるファイルに対たいして、リビジョンN-1中ちゅうに同おなじ名前なまえのファイルがあれば、それが元もとファイルと考かんがえられる。しかし、リビジョンN-1中ちゅうに似にたような名前なまえのファイルがない場合ばあいもある。この場合ばあいGitは、リビジョンN-1のみに存在そんざいし、かつ似にたような内容ないようのファイルを検索けんさくする。）しかし、この処理しょりは履歴りれきの表示ひょうじを行おこなう度たびにCPUに負荷ふかのかかる処理しょりが必要ひつようとなる。そのため、使用しようするヒューリスティックを選択せんたくするオプションが提供ていきょうされている。

リポジトリの保存ほぞん方法ほうほうについては批判ひはんもある。

• Gitは新あたらしく作成さくせいされたオブジェクトを個別こべつのファイルの形かたちで保存ほぞんする。各かくファイルは圧縮あっしゅくされて保存ほぞんされるが、そうであったとしてもこの方法ほうほうは記録きろく領域りょういきを大量たいりょうに必要ひつようとするため非ひ効率こうりつ的てきである。Gitはこの問題もんだいを“pack”を使用しようすることで解決かいけつしている。複数ふくすうのオブジェクトは一ひとつのファイル（またはネットワークバイトストリーム）の形かたちにパックされ、各かくpack間あいだで差分さぶん圧縮あっしゅくが行おこなわれる。packの差分さぶん圧縮あっしゅくにはヒューリスティックが用もちいられる。例たとえば、同おなじ名前なまえのファイルは似にた内容ないようである可能かのう性せいが高たかいものとして処理しょりされる。ただし、リポジトリの正確せいかく性せいを保たもつため、ヒューリスティックに完全かんぜんに依存いぞんすることはない。現在げんざいのGitでも新あたらしく作成さくせいされたオブジェクト（新あたらしく加くわえられた履歴りれき）はまず単一たんいつのファイルとして保存ほぞんされるため、空間くうかん効率こうりつを高たかく保たもつためには定期ていき的てきな再さいパックが要求ようきゅうされる。Gitはこの定期ていき的てきな再さいパックを自動的じどうてきに行おこなうが、git gcコマンドを使用しようすることで手動しゅどうで再さいパックを行おこなうこともできる。

Gitは以下いかのマージアルゴリズムを実装じっそうしている。アルゴリズムはマージ時じに選択せんたくすることができる。

resolve

従来じゅうらい通どおりの3-wayマージアルゴリズムを使用しようする。

recursive

3-wayマージの変種へんしゅを使用しようする。ブランチのmergeやpullを行おこなう場合ばあいのデフォルトである。3-wayマージにおいて共通きょうつうの祖先そせんが複数ふくすうある場合ばあい、共通きょうつうの祖先そせんからのmerge treeを作成さくせいし、それをreference treeとして3-wayマージを行おこなう。Linuxカーネル2.6の開発かいはつで行おこなわれたマージコミットの履歴りれきから、このアルゴリズムを使用しようするとマージの衝突しょうとつが少すくなく、マージ漏もれもなかったことが報告ほうこくされている。さらに、リネームを伴ともなうマージに対たいしても検出けんしゅつおよび処理しょりが可能かのうである。

octopus

3つ以上いじょうのheadからのマージを行おこなう場合ばあいのデフォルトである。

歴史れきし

名前なまえの由来ゆらい

リーナス・トーバルズによれば、

「

僕ぼくは自己じこ中心ちゅうしん的てきな奴やつだから、自分じぶんのプロジェクトには自分じぶんにちなんだ名前なまえを付つけるようにしているんだ。最初さいしょはLinuxで、今度こんどはGitだ。

」

英語えいごのスラングとして、Gitには「バカ」「間抜まぬけ」といった類るいの意味いみがある。この自虐じぎゃくネタはもちろん皮肉ひにくで、これはリーナスがLinuxの名前なまえを決きめる際さいに自身じしんの名前なまえにちなんだ名前なまえを付つけるよう強要きょうようされたことから来きている。(Linux#名前なまえの由来ゆらいを参照さんしょう)

Gitのオフィシャルサイトのウィキでは、“Git”という名前なまえに対たいして他ほかにもいくつかの解釈かいしゃくがなされている。例れいとしてはGlobal Information Trackerなどが挙あげられる。

開発かいはつ初期しょきの歴史れきし

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分ふんで気きがつくなら、それで十分じゅうぶんで、手作業てさぎょうで修正しゅうせいすることができる。待まち時間じかんが重要じゅうような理由りゆうはそこにある。-- "オフライン" で効果こうか的てきにそれができるなら、問題もんだいが起おきた時ときに僕ぼくは定義ていぎどおりそれを修理しゅうりできずにいるだろう）

」

リーナスは以下いかのような原則げんそくに基もとづいて設計せっけいを行おこなっている。

1. CVSを「悪わるい見本みほん」とする。設計せっけい上じょうのことで確信かくしんが持もてない場合ばあいは、CVSと逆ぎゃくの決断けつだんをする。リーナスは冗談じょうだんめかして以下いかのように語かたっている。
   • “カーネルメンテナンスの最初さいしょの10年間ねんかん、僕ぼくらは文字通もじどおりtarボールとパッチを使つかっていた。CVSよりもずっと優すぐれたソース管理かんりシステムさ。僕ぼくは営利えいり企業きぎょう（トランスメタ）でCVSを7年間ねんかん使つかわされたことで、CVSを強烈きょうれつに憎にくむようになった。CVSを強烈きょうれつに憎にくんでいると言いう時ときには、このことも言いっておかなくちゃいけないね。観衆かんしゅうの中なかにSVN (Subversion) のユーザがいるなら、この場ばから去さったほうがいいかもしれない。僕ぼくがCVSを強烈きょうれつに嫌悪けんおしているということは、僕ぼくがSubversionが史上しじょう最大さいだいの無意味むいみなプロジェクトであると思おもっていることも意味いみしているんだ。Subversionのしばらくのスローガンは‘ちゃんとCVSをやる’とかそんなものだったよね。そんなスローガンから始はじめたら、どこにも辿たどりつけないよ。CVSをちゃんとやるなんて不可能ふかのうなのさ。”
2. 分散ぶんさん型がたの、BitKeeperのようなワークフローをサポートする。
   • “BitKeeperだけが、「まあ使つかってもいいかな」と最初さいしょに思おもわせてくれたSCMだというわけではないけれど、BitkeeperはSCMというものの存在そんざい意義いぎと、実際じっさいにどう使つかうことができるのかを教おしえてくれた。だから、Gitは技術ぎじゅつ的てきな観点かんてんとかいろんなところでBitkeeperとは随分ずいぶん違ちがうものになっているけど（それはもう一ひとつの設計せっけい目標もくひょうでもある。Bitkeeperのクローンではないことをはっきりさせたかったから）、Gitのワークフローの多おおくは、Bitkeeperが教おしえてくれたフローから直接ちょくせつきたものになっているんだ。”
3. データ破壊はかいに対たいする強力きょうりょくな抑止よくし機能きのう。データ破壊はかいは、偶然ぐうぜんによるものと意図いと的てきなものの両方りょうほうを想定そうていしている。
4. 非常ひじょうに高たかい処理しょり速度そくど。

最初さいしょの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月がつ現在げんざいも彼かれがメンテナンスを行おこなっている。

ブランチモデル

ソフトウェア開発かいはつにおけるGitブランチの作成さくせい・更新こうしんモデルをブランチモデルと呼よぶ。

GitHub flow

GitHub flowはブランチモデルの一種いっしゅである。GitHub flowの方針ほうしんは「masterブランチは常つねにデプロイ可能かのう」である。コードの変更へんこうを行おこなう際さいにはトピックを名称めいしょうとするブランチを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されている。このモデル変更へんこうにより、CIで判明はんめいしなかったバグが発生はっせいした場合ばあいにmasterのrevert commitではなくmasterの再さいデプロイで対応たいおうできる。

マージ

Gitはブランチのマージ（merge）に対応たいおうしている。

マージが行おこなわれるとマージコミット（英えい: merge commit）が生成せいせいされる。コンフリクトが発生はっせいしない場合ばあい、git mergeがマージコミットを自動じどう生成せいせいする。コンフリクトが発生はっせいした場合ばあい、まず安全あんぜんな範囲はんいがマージされインデックスとワーキングツリーが更新こうしんされる。自動じどうマージできないコンフリクト部ぶは、ワーキングツリーに特定とくていの記法きほうで両方りょうほうの変更へんこうが併記へいきされた状態じょうたいになる。ユーザーによるコンフリクト修正しゅうせい後ごgit addをおこない、git commitあるいはgit merge --continueをおこなってはじめてマージコミットが生成せいせいされる。

マージコミットの実体じったいは2つ以上いじょうのparent属性ぞくせいを持もつただのコミットオブジェクトである（特別とくべつなGitオブジェクトではない）。通常つうじょうのコミットオブジェクトと同様どうように変更へんこう後ごファイルセットがtreeに記録きろくされ、更新こうしんの元もととなっている（複数ふくすうの）コミットがparentに設定せっていされているだけである。

関連かんれん項目こうもく

• GitHub
• バージョン管理かんりシステム
• arch
• Bazaar
• BitKeeper - Git以前いぜんにLinuxカーネル開発かいはつで使用しようされていたバージョン管理かんりシステム。ライセンス発行はっこうに関かかわる問題もんだいによりGitが開発かいはつされることとなった。
• Concurrent Versions System (CVS)
• Mercurial - Gitとほぼ同どう時期じきに開発かいはつが開始かいしされた。
• Apache Subversion

外部がいぶリンク

• Git - 公式こうしきウェブサイト（英語えいご）
• Index of /pub/software/scm/git/ - Gitの配布はいふディレクトリ
• Git for Windows - Windows版ばんGitの配布はいふサイト。（英語えいご）
• Pro Git book（英語えいご）
• Pro Git book（日本語にほんご）