Git

トーバルズは、 gitという名前（イギリス英語のスラングで、不愉快な人や愚かな人を意味する）について、「私は自己中心的な野郎で、自分のプロジェクトにはすべて自分の名前を付けている。最初は『Linux』、今度は『git』だ」と冗談を言った。^{[ 33 ] [ 34 ]} manページでは Git を「愚かなコンテンツ トラッカー」と説明している。^{[ 35 ]}

ソースコードのreadmeファイルにはさらに詳しい説明があります。^{[ 36 ]}

「git」という言葉は、気分次第でどんな意味にもなり得る。

• 発音可能なランダムな3文字の組み合わせで、一般的なUNIXコマンドでは実際には使用されていない。「get」の誤った発音であるという事実は、関連性がある場合もあれば、ない場合もある。
• 愚か。軽蔑すべき、卑劣な。単純明快。スラング辞典から好きな言葉を選んでください。
• 「グローバル情報トラッカー」：気分が良く、実際に効果を発揮します。天使たちが歌い、突然部屋が光で満たされます。
• 壊れた時の「とんでもなくバカげたクソの山」。

Gitのソースコードでは、このプログラムを「地獄から来た情報マネージャー」と呼んでいる。^{[ 37 ] [ 38 ]}

Git の設計は、大規模な分散開発プロジェクトを維持してきた Torvalds の Linux に関する経験と、同じプロジェクトから得たファイルシステムのパフォーマンスに関する深い知識、そして短期間で動作するシステムを作成する必要性の合理化です。これらの影響により、次の実装上の選択が行われました: ^{[ 10 ]}

非線形開発に対する強力な支援

Gitは迅速なブランチ作成とマージをサポートし、非線形な開発履歴を視覚化およびナビゲートするための専用ツールを備えています。Gitでは、変更はさまざまなレビュー担当者に渡されるため、記述されるよりもマージされる頻度が高いという前提があります。Gitのブランチは非常に軽量で、ブランチは単一のコミットへの参照にすぎません。

分散開発

Darcs、BitKeeper、Mercurial、Bazaar、Monotoneと同様に、Gitは各開発者に完全な開発履歴のローカルコピーを提供し、変更はこのようなリポジトリ間でコピーされます。これらの変更は追加された開発ブランチとしてインポートされ、ローカルで開発されたブランチと同じ方法でマージできます。^{[ 39 ]}

既存のシステムおよびプロトコルとの互換性

リポジトリは、HTTPS ( Hypertext Transfer Protocol Secure )、 HTTP ( Hypertext Transfer Protocol )、FTP ( File Transfer Protocol )、またはプレーンソケットもしくはセキュアシェル(ssh) を介した Git プロトコルによって公開できます。Git には CVS サーバーエミュレーションもあり、既存の CVS クライアントや IDE プラグインを使用して Git リポジトリにアクセスできます。Subversionリポジトリは git-svn で直接使用できます。^{[ 40 ]}

大規模プロジェクトの効率的な処理

トーバルズはGitを非常に高速でスケーラブルだと評しており^{[ 41 ]}、Mozillaが行ったパフォーマンス テスト^{[ 42 ]}では、大規模なリポジトリの差分比較においてMercurialやGNU Bazaarよりも桁違いに高速であることが示されました。ローカルに保存されたリポジトリからバージョン履歴を取得する速度は、リモート サーバーから取得する速度の100倍にもなります^{[ 43 ] 。}

履歴の暗号認証

Gitの履歴は、特定のバージョン（Gitではコミット）のIDが、そのコミットに至るまでの完全な開発履歴に依存するように保存されます。一度公開されると、古いバージョンを変更しても気づかれないことはありません。構造はマークルツリーに似ていますが、ノードとリーフにデータが追加されています。^{[ 44 ]}（MercurialとMonotoneもこの特性を持っています。）

ツールキットベースの設計

Git は、 C言語で書かれた一連のプログラムと、それらのプログラムをラップするいくつかのシェル スクリプトとして設計されました。^{[ 45 ]}その後、速度と移植性のためにほとんどのスクリプトが C 言語で書き直されましたが、設計はそのまま残っており、コンポーネントを簡単に連結できます。^{[ 46 ]}

プラグイン可能なマージ戦略

Gitはツールキット設計の一環として、不完全なマージの明確なモデルを持ち、それを完了するための複数のアルゴリズムを備えており、最終的にはマージを自動的に完了できないため手動での編集が必要であることをユーザーに通知します。^{[ 47 ]}

ゴミは収集されるまで蓄積される

操作を中止したり変更を元に戻したりすると、データベースに不要なオブジェクトが残ります。これらは通常、継続的に増加する必要なオブジェクトの履歴のごく一部です。リポジトリに十分な数の不要なオブジェクトが作成されると、Git は自動的にガベージ コレクションを実行します。ガベージ コレクションは、明示的に呼び出すことができますgit gc。^{[ 48 ] [ 49 ]}

周期的な明示的オブジェクトパッキング

Git は新しく作成されたオブジェクトをそれぞれ個別のファイルとして保存します。個別に圧縮されますが、これは大量のスペースを消費し、非効率的です。この問題は、多数のオブジェクトを差分圧縮して1 つのファイル (またはネットワーク バイト ストリーム) に格納するパックを使用することで解決されます。このパックはパック ファイルと呼ばれます。パックは、同じ名前のファイルはおそらく類似しているというヒューリスティックを使用して圧縮されますが、正確性についてはこのヒューリスティックに依存しません。各パック ファイルに対応するインデックス ファイルが作成され、パック ファイル内の各オブジェクトのオフセットが記録されます。新しく作成されたオブジェクト (新しく追加された履歴を含む) は、依然として単一のオブジェクトとして保存され、スペース効率を維持するために定期的な再パックが必要です。リポジトリをパックするプロセスは、非常に計算コストがかかる場合があります。Git は、オブジェクトを緩いが迅速に生成される形式でリポジトリに存在させることで、コストのかかるパック操作を、時間があまり重要でない後 (たとえば、勤務日の終わり) まで延期できるようにします。Git は定期的な再パックを自動的に行いますが、コマンドを使用して手動で再パックすることも可能です。^{[ 50 ]}データの整合性を確保するため、パックファイルとそのインデックスの両方にSHA-1チェックサム^{[ 51 ]}が含まれており、パックファイルのファイル名にもSHA-1チェックサムが含まれています。リポジトリの整合性を確認するには、コマンドを実行します。^{[ 52 ] [ 53 ]}git gcgit fsck

Git のもう 1 つの特性は、ファイルのディレクトリ ツリーのスナップショットを作成することです。ソース コードのバージョンを追跡する初期のシステムであるソース コード コントロール システム(SCCS) とリビジョン コントロール システム(RCS) は、個々のファイルに対して動作し、(ほとんど同じ) バージョンをインターリーブ デルタ(SCCS) またはデルタ エンコーディング(RCS)することで得られるスペースの節約を重視していました。後のリビジョン コントロール システムでは、プロジェクトの複数のリビジョンにわたってファイルが同一であるというこの概念が維持されました。しかし、トーバルズはこの概念を拒否しました。^{[ 54 ]}その結果、Git はソース コード ツリーより下のどのレベルでもファイルのリビジョン関係を明示的に記録しません。

Git はいくつかのマージ戦略を実装しており、マージ時にデフォルト以外の戦略を選択できます。^{[ 60 ]}

• resolve：従来の3方向マージアルゴリズム。
• recursive：これは、1つのブランチをプルまたはマージする場合のデフォルトであり、3方向マージアルゴリズムのバリアントです。

  3方向マージに使用できる共通祖先が複数存在する場合、それらの共通祖先のマージ済みツリーを作成し、それを3方向マージの参照ツリーとして使用します。Linux 2.6カーネル開発履歴から取得した過去のマージコミットに対するテストでは、この方法によりマージの競合が減少し、誤ったマージが発生することもないことが報告されています。また、名前変更を伴うマージも検出して処理できます。

  —リーナス・トーバルズ^{[ 61 ]}

• タコ：これは、2つ以上の頭部を結合する場合のデフォルト設定です。

Git の基本機能は、本質的にソースコード管理システムではありません。トーバルズは次のように説明しています。^{[ 62 ]}

多くの点で、Gitは単なるファイルシステムと見なすことができます。コンテンツアドレス指定が可能で、バージョン管理の概念も備えていますが、私はファイルシステムの専門家（カーネル開発者です）の視点からこの問題に取り組み、設計しました。そして、従来型のSCMシステムを作成することには全く興味がありません。

この初期設計アプローチから、Gitは従来のSCMに期待される機能一式を開発しました^{[ 63 ]。}機能のほとんどは必要に応じて作成され、その後、時間の経過とともに改良および拡張されました。

Gitには2つのデータ構造があります。1つは作業ディレクトリとコミットされる次のリビジョンに関する情報をキャッシュする可変インデックス（ステージまたはキャッシュとも呼ばれます） 、もう1つは不変オブジェクトを格納するオブジェクトデータベースです。^{[ 64 ]}

インデックスは、オブジェクトデータベースと作業ツリー間の接続点として機能します。 ^{[ 64 ]}

オブジェクトストアには 5 種類のオブジェクトが含まれています: ^{[ 65 ] [ 52 ]}

• ブロブはファイルの内容です。ブロブには適切なファイル名、タイムスタンプ、その他のメタデータはありません（ブロブの名前は内部的にはその内容のハッシュです）。Gitでは、各ブロブはファイルのバージョンであり、その中にファイルのデータが含まれています。^{[ 66 ]}
• ツリーオブジェクトはディレクトリに相当します。ツリーオブジェクトにはファイル名のリストが含まれており、各^ファイル名にはいくつかの型ビットと、そのファイル、シンボリックリンク、またはディレクトリの内容であるブロブまたはツリーオブジェクトへの参照が含まれています。[ ^{67 ]}これらのオブジェクトはソースツリーのスナップショットです。（全体として、これはマークルツリーを構成します。つまり、ルートツリーの単一のハッシュだけで十分であり、コミットで実際に使用され、任意の数のサブディレクトリとファイルのツリー構造全体の正確な状態を正確に特定できます。）
• コミットオブジェクトは、ツリーオブジェクトを履歴にリンクします。これには、ツリーオブジェクトの名前（最上位ソースディレクトリ）、タイムスタンプ、ログメッセージ、および0個以上の親コミットオブジェクトの名前が含まれます。^{[ 68 ]}
• タグオブジェクトは、別のオブジェクトへの参照を含むコンテナであり、別のオブジェクトに関連する追加のメタデータを保持できます。最も一般的には、Git で追跡されているデータの特定のリリースに対応するコミットオブジェクトのデジタル署名を保存するために使用されます。 ^{[ 69 ]}
• パックファイルオブジェクトは、さまざまな他のオブジェクトをzlibで圧縮されたバンドルにまとめて、コンパクト化とネットワークプロトコルを介した転送の容易化を図ります。^{[ 70 ]}

各オブジェクトは、その内容のSHA-1ハッシュによって識別されます。Gitはこのハッシュを計算し、その値をオブジェクト名として使用します。オブジェクトは、ハッシュの最初の2文字に一致するディレクトリに配置されます。ハッシュの残りの部分は、そのオブジェクトのファイル名として使用されます。

Git はファイルの各リビジョンを固有のブロブとして保存します。ブロブ間の関係は、ツリーとコミットオブジェクトを調べることで確認できます。新しく追加されたオブジェクトは、zlib 圧縮を使用して全体が保存されます。これはすぐに大量のディスク容量を消費する可能性があるため、オブジェクトをパックにまとめることができます。パックはデルタ圧縮を使用して容量を節約し、ブロブを他のブロブに対する変更点として保存します。

さらに、Git はさまざまなコミットの場所を示すために、refs (references の略) と呼ばれるラベルを保存します。これらは参照データベースに保存され、それぞれ次のようになります。^{[ 71 ]}

• ヘッド（ブランチ）：その上にコミットが作成される際に、自動的に新しいコミットに更新される名前付き参照。
• HEAD：コミットを作成するために作業ツリーと比較される予約済みのヘッド。
• タグ：ブランチ参照に似ていますが、特定のコミットに固定されています。履歴上の重要なポイントを示すために使用されます。

Gitのコマンドラインインターフェースでよく使われるコマンドには、次のものがあります。^{[ 72 ] [ 73 ]}

• git initこれは、Gitリポジトリを作成するために使用されます。
• git clone [URL]これは、外部URLからGitリポジトリをクローン、つまり複製します。
• git add [file]これは、git の作業ディレクトリ(コミットしようとしているファイル)にファイルを追加します。
• git commit -m [commit message]これは、現在の作業ディレクトリにあるファイルをコミットします（そのため、それらのファイルはリポジトリの履歴の一部になります）。

.gitignoreファイルは、 Git リポジトリにプレーンテキストファイルとして作成できます。.gitignoreファイルにリストされているファイルは、Gitによって追跡されません。^{[ 74 ] : 3-4}この機能を使用すると、キーやパスワードを含むファイル、さまざまな不要なファイル、および大きなファイル ( GitHub がアップロードを拒否するファイル) を無視できます。^{[ 75 ]}

Gitデータベース内の参照されていないオブジェクトはすべて、ガベージコレクションコマンドを使用するか、自動的にクリーンアップされます。オブジェクトは、別のオブジェクトまたは明示的な参照によって参照されることがあります。Gitにはさまざまな種類の参照があります。参照の作成、移動、削除を行うコマンドはそれぞれ異なります。git show-refすべての参照を一覧表示します。いくつかの種類は次のとおりです。

• heads : ローカルなオブジェクトを参照します。
• remotes : リモートリポジトリに存在するオブジェクトを指します。
• stash : まだコミットされていないオブジェクトを指します。
• meta :例: ベアリポジトリ内の構成、ユーザー権限。refs/meta/config 名前空間は遡及的に導入され、Gerritで使用されています。^{[ 76 ]}
• タグ：上記参照。

• Hosting the Git server using the Git Binary.^[100]
• Gerrit, a Git server configurable to support code reviews and provide access via ssh, an integrated Apache MINA or OpenSSH, or an integrated Jetty web server. Gerrit provides integration for LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https client certificates. With Gerrit 3.0 all configurations will be stored as Git repositories, and no database is required to run. Gerrit has a pull-request feature implemented in its core but lacks a GUI for it.
• Phabricator, a spin-off from Facebook. As Facebook primarily uses Mercurial, Git support is not as prominent.^[101]
• RhodeCode Community Edition (CE), supporting Git, Mercurial and Subversion with an AGPLv3 license.
• Kallithea, supporting both Git and Mercurial, developed in Python with GPL license.
• External projects like gitolite,^[102] which provide scripts on top of Git software to provide fine-grained access control.
• There are several other FLOSS solutions for self-hosting, including Gogs,^[103]Gitea, a fork of Gogs, as well as Forgejo, which is, in turn, a fork of Gitea. Gogs, as well as the two aforementioned derivatives of it, is developed using the Go language. All three solutions are made available under the MIT license.

Gitリポジトリをサービスとして提供するサービスは数多くあります。最も人気のあるものはGitHub、SourceForge、Bitbucket、GitLabです。^{[ 104 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ]}

Gitには多くの拡張機能があり、例えばGit LFSはGitHubコミュニティでGitの拡張機能として開発が始まり、現在では他のリポジトリでも広く利用されています。拡張機能は通常、異なる人々によって独立して開発・保守されていますが、将来的には広く利用されている拡張機能がGitに統合される可能性もあります。

その他のオープンソースのGit拡張機能には以下が含まれます。

• Git-annexは、Gitをベースとした分散ファイル同期システムです。
• git-flow は、Vincent Driessen のブランチングモデルに対して高レベルのリポジトリ操作を提供する Git 拡張機能のセットです。
• git-macheteは、リポジトリの整理と、リベース/マージ/プル/プッシュ操作の自動化のためのツールです。

Microsoft は、2017 年にPerforceから移行した際に、 Windowsソースコードツリーのサイズを処理するために、Virtual File System for Git (VFS for Git、旧称 Git Virtual File System または GVFS) 拡張機能を開発しました。VFS for Git を使用すると、クローンされたリポジトリでプレースホルダーを使用でき、その内容はファイルにアクセスされたときにのみダウンロードされます。^{[ 119 ]}