代替メカニズムを介して、リポジトリはオブジェクトデータベースの一部を別のオブジェクトデータベース（「代替」と呼ばれる）から継承できます。

ベアリポジトリは通常、バージョン管理下のファイルのローカルチェックアウトコピーを持たない、適切に命名された .git 接尾辞を持つディレクトリです。つまり、隠された .git サブディレクトリに通常存在するすべての Git 管理ファイルおよび制御ファイルは、代わりに repository.git ディレクトリに直接存在し、他のファイルは存在せずチェックアウトもされていません。通常、公開リポジトリの公開者はベアリポジトリを利用可能にします。

型のないオブジェクト。例えば、ファイルの内容。

「ブランチ」とは、開発の流れのことです。ブランチ上の最新のコミットは、そのブランチの先端と呼ばれます。ブランチの先端はブランチのヘッドによって参照され、ブランチ上で追加の開発が行われるにつれて前方へ移動します。単一のGitリポジトリは任意の数のブランチを追跡できますが、あなたの作業ツリーはそれらのうちの1つ（「現在の」または「チェックアウトされた」ブランチ）に関連付けられており、HEADはそのブランチを指しています。

廃止されました: インデックス。

オブジェクトのリストで、リスト内の各オブジェクトがその次のオブジェクトへの参照を含んでいます（例えば、コミットの次はその親の1つになりえます）。

BitKeeper/cvsps の用語で、「コミット」を意味します。Git は変更ではなく状態を保存するため、Git で「チェンジセット」という用語を使用するのは意味がありません。

オブジェクトデータベースからツリーオブジェクトまたはブロブを使用して、作業ツリーのすべてまたは一部を更新するアクション。作業ツリー全体が新しいブランチを指している場合は、インデックスとHEADも更新します。

SCMの専門用語で、「チェリーピック」とは、一連の変更（通常はコミット）から変更のサブセットを選択し、別のコードベースの上に新しい一連の変更として記録することを意味します。Gitでは、既存のコミットによって導入された変更を抽出し、現在のブランチの先端をベースとして新しいコミットとして記録するために、「git cherry-pick」コマンドによって実行されます。

作業ツリーは、現在のヘッドによって参照されるリビジョンに対応している場合、クリーンであると言えます。「ダーティ」も参照してください。

名詞として：Git履歴内の単一のポイント。プロジェクトの全履歴は、相互に関連するコミットのセットとして表されます。「コミット」という言葉は、他のバージョン管理システムが「リビジョン」または「バージョン」という言葉を使用するのと同じ場所で、Gitによってしばしば使用されます。コミットオブジェクトの略語としても使用されます。

オブジェクトデータベース内のコミットによって形成されるDAG構造の同義語で、チェーンされたコミットのチェーンを使用してブランチの先端によって参照されます。この構造が決定的なコミットグラフです。グラフは他の方法でも表現できます。例えば、「コミットグラフ」ファイル。

「コミットグラフ」（通常はハイフンで区切られる）ファイルは、コミットグラフを補完的に表現するもので、コミットグラフの探索を高速化します。「コミットグラフ」ファイルは、.git/objects/info ディレクトリ、または代替オブジェクトデータベースの info ディレクトリに保存されます。

特定のリビジョンに関する情報（親、コミッター、作者、日付、および保存されたリビジョンの最上位ディレクトリに対応するツリーオブジェクトなど）を含むオブジェクト。

コミットオブジェクト、またはコミットオブジェクトに再帰的にデリファレンスできるオブジェクト。以下のすべてがコミットっぽいものです：コミットオブジェクト、コミットオブジェクトを指すタグオブジェクト、コミットオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。

Git の基本的なデータ構造とユーティリティ。限られたソースコード管理ツールのみを公開しています。

有向非巡回グラフ。コミットオブジェクトは親を持つ（有向）ため有向であり、コミットオブジェクトのグラフは非巡回である（同じオブジェクトで始まり終わるチェーンが存在しない）ため、有向非巡回グラフを形成します。

他の到達不能なオブジェクトからも到達不能な到達不能なオブジェクト。つまり、ぶら下がりオブジェクトには、リポジトリ内のどの参照やオブジェクトからも参照されていません。

シンボリックリファレンスを参照する場合: シンボリックリファレンスが指すリファレンスにアクセスするアクション。再帰的なデリファレンスには、非シンボリックリファレンスが見つかるまで、結果のリファレンスに対して前述のプロセスを繰り返すことが含まれます。

通常、HEADはブランチの名前を格納し、HEADが表す履歴を操作するコマンドは、HEADが指すブランチの先端に至る履歴を操作します。しかし、Gitでは、特定のブランチの先端である必要のない任意のコミットをチェックアウトすることもできます。このような状態のHEADは「分離」状態と呼ばれます。

「ls」で得られるリストです :-)

作業ツリーは、現在のブランチにコミットされていない変更が含まれている場合、「ダーティ」であると言われます。

不正なマージとは、どの親にも現れない変更を導入するマージのことです。

ファストフォワードとは、あるリビジョンを持っていて、それが自身の祖先である別のブランチの変更を「マージ」する特殊なタイプのマージです。このような場合、新しいマージコミットを作成するのではなく、ブランチをマージしようとしているブランチと同じリビジョンを指すように更新するだけです。これは、リモートリポジトリのリモートトラッキングブランチで頻繁に発生します。

ブランチをフェッチするということは、リモートリポジトリからブランチのヘッド参照を取得し、ローカルのオブジェクトデータベースに不足しているオブジェクトを見つけ出し、それらも取得することです。詳しくはgit-fetch[1]を参照してください。

リーナス・トーバルズは元々Gitをユーザー空間ファイルシステム、つまりファイルやディレクトリを保持するためのインフラストラクチャとして設計しました。これにより、Gitの効率と速度が保証されました。

リポジトリの同義語（arch ユーザー向け）。

作業ツリーのルートにあるプレーンファイル .git で、実際のリポジトリであるディレクトリを指します。適切な使用方法については、git-worktree[1] または git-submodule[1] を参照してください。構文については、gitrepository-layout[5] を参照してください。

グラフトにより、コミットに偽の祖先情報を記録することで、それ以外は異なる2つの開発ラインを結合することができます。これにより、Gitはコミットが作成されたときに記録されたものとは異なる親のセットを持っているかのように振る舞わせることができます。.git/info/grafts ファイルで設定します。

Gitの文脈では、オブジェクト名の同義語。

ブランチの先端にあるコミットへの名前付き参照。ヘッドは、パックされた参照を使用する場合を除き、$GIT_DIR/refs/heads/ ディレクトリのファイルに保存されます。（git-pack-refs[1] を参照してください。）

現在のブランチ。より詳細には：あなたの作業ツリーは通常、HEADが参照するツリーの状態から派生します。HEADはリポジトリ内のヘッドの1つへの参照ですが、分離HEADを使用している場合は、任意のコミットを直接参照します。

ヘッドの同義語。

いくつかの Git コマンドの通常の実行中に、開発者が機能を追加したりチェックを行ったりするためのオプションのスクリプトが呼び出されます。通常、フックはコマンドが事前に検証され、場合によっては中止されることを可能にし、操作完了後の通知も可能にします。フックスクリプトは $GIT_DIR/hooks/ ディレクトリにあり、ファイル名から .sample 接尾辞を削除するだけで有効になります。以前のバージョンの Git では、実行可能にする必要がありました。

統計情報を持つファイルの集合で、その内容はオブジェクトとして保存されます。インデックスはあなたの作業ツリーの保存されたバージョンです。実を言うと、マージの際に使用される作業ツリーの2番目、さらには3番目のバージョンも含むことができます。

インデックスに保存されている、特定のファイルに関する情報。マージが開始されたもののまだ完了していない場合（つまり、インデックスにそのファイルの複数のバージョンが含まれている場合）、インデックスエントリはマージされていない状態である可能性があります。

デフォルトの開発ブランチ。Git リポジトリを作成すると、「master」という名前のブランチが作成され、アクティブなブランチになります。ほとんどの場合、これがローカル開発を含みますが、それは純粋に慣例によるものであり、必須ではありません。

動詞として: 別のブランチ (外部のリポジトリである可能性もある) の内容を現在のブランチに取り込むこと。マージされるブランチが異なるリポジトリからのものである場合、これはまずリモートブランチをフェッチし、その結果を現在のブランチにマージすることで行われます。このフェッチとマージ操作の組み合わせをプルと呼びます。マージは、ブランチが分岐して以来行われた変更を識別し、それらの変更をすべてまとめて適用する自動プロセスによって実行されます。変更が競合する場合、マージを完了するために手動での介入が必要になることがあります。

Gitにおけるストレージの単位。その内容のSHA-1によって一意に識別されます。したがって、オブジェクトは変更できません。

一連の「オブジェクト」を格納し、個々のオブジェクトはそのオブジェクト名によって識別されます。オブジェクトは通常、$GIT_DIR/objects/ に存在します。

オブジェクト名の同義語。

オブジェクトの一意の識別子。オブジェクト名は通常40文字の16進文字列で表されます。口語的にはSHA-1とも呼ばれます。

オブジェクトのタイプを記述する識別子「commit」、「tree」、「tag」、「blob」のいずれか。

2つ以上のブランチをマージすること。

まだ存在しないブランチ（つまり、未作成ブランチ）に乗る行為。このような操作の後、最初に作成されたコミットは親を持たないコミットとなり、新しい履歴が開始されます。

デフォルトのアップストリームリポジトリ。ほとんどのプロジェクトには、追跡するアップストリームプロジェクトが少なくとも1つあります。デフォルトでは、その目的のためにoriginが使用されます。新しいアップストリームの更新は、git branch -r を使用して確認できる、origin/name-of-upstream-branchという名前のリモートトラッキングブランチにフェッチされます。

作業ディレクトリのファイルを更新および追加するだけで、削除はしません。これは、cp -Rが宛先ディレクトリの内容を更新する方法と似ています。インデックスまたはツリーライクからファイルをチェックアウトする場合のチェックアウトのデフォルトモードです。対照的に、no-overlayモードは、ソースに存在しない追跡ファイルも削除します。これは、rsync --deleteと似ています。

1つのファイルに圧縮されたオブジェクトのセット（スペースを節約したり、効率的に転送したりするため）。

パックの内容に効率的にアクセスするために、パック内のオブジェクトの識別子とその他の情報のリスト。

Git コマンドでパスを制限するために使用されるパターン。

コミットオブジェクトは、開発ラインにおける論理的な先行者（つまり、その親）の（空の可能性のある）リストを含みます。

タグオブジェクトを再帰的にデリファレンスする動作。

「ピッケル」という用語は、特定のテキスト文字列を追加または削除する変更を選択するのに役立つdiffcoreルーチンへのオプションを指します。--pickaxe-all オプションを使用すると、特定のテキスト行を導入または削除した完全なチェンジセットを表示するために使用できます。git-diff[1] を参照してください。

コア Git の可愛い名前。

コア Git に依存するプログラムやプログラムスイートの可愛い名前で、コア Git への高レベルなアクセスを提供します。ポーセリンは、配管よりもSCMインターフェースの多くを公開しています。

グローバルではなく、ワークツリーごとの参照です。現在はHEADとrefs/bisect/で始まる参照のみですが、将来的には他の特殊な参照も含まれる可能性があります。

通常の参照とは異なるセマンティクスを持つ参照。これらの参照は通常のGitコマンドで読み取ることができますが、git-update-ref[1]などのコマンドで書き込むことはできません。

ブランチをプルするとは、そのブランチをフェッチしてマージすることです。git-pull[1]も参照してください。

ブランチをプッシュするとは、リモートリポジトリからブランチのヘッド参照を取得し、それがブランチのローカルヘッド参照の祖先であるかどうかを判断し、その場合、ローカルヘッド参照から到達可能で、リモートリポジトリに存在しないすべてのオブジェクトをリモートオブジェクトデータベースに入れ、リモートヘッド参照を更新することです。リモートヘッドがローカルヘッドの祖先でない場合、プッシュは失敗します。

あるコミットのすべての祖先は、そのコミットから「到達可能」であると言われます。より一般的には、あるオブジェクトから別のオブジェクトへ、タグが指すもの、コミットがその親またはツリー、ツリーがその中に含まれるツリーまたはブロブへと辿るチェーンを介して到達できる場合、そのオブジェクトは別のオブジェクトから到達可能であると言われます。

到達可能性ビットマップは、パックファイル内、またはマルチパックインデックス (MIDX) 内で選択されたコミットセットの到達可能性に関する情報を格納し、オブジェクト検索を高速化します。ビットマップは ".bitmap" ファイルに保存されます。リポジトリは最大1つのビットマップファイルを使用できます。ビットマップファイルは、単一のパック、またはリポジトリのマルチパックインデックス (存在する場合) のいずれかに属します。

ブランチからの変更のシリーズを別のベースに再適用し、そのブランチのヘッドを結果にリセットすること。

オブジェクト名または別の参照を指す名前（後者はシンボリック参照と呼ばれる）。便宜上、Gitコマンドの引数として使用される場合、参照は省略されることがあります。詳細はgitrevisions[7]を参照してください。参照はリポジトリに保存されます。

リフログは、参照のローカルな「履歴」を示します。言い換えれば、このリポジトリで3つ前のリビジョンが何であったか、昨日午後9時14分にこのリポジトリの現在の状態が何であったかを知ることができます。詳細はgit-reflog[1]を参照してください。

「refspec」はフェッチとプッシュによって、リモート参照とローカル参照間のマッピングを記述するために使用されます。詳細はgit-fetch[1]またはgit-push[1]を参照してください。

同じプロジェクトを追跡するために使用されるが、別の場所に存在するリポジトリ。リモートとの通信については、フェッチまたはプッシュを参照してください。

別のリポジトリからの変更を追跡するために使用される参照。通常はrefs/remotes/foo/bar（リモートfooのbarというブランチを追跡していることを示す）のように見え、設定されたフェッチリフスペックの右辺と一致します。リモートトラッキングブランチには、直接的な変更やローカルコミットを含めるべきではありません。

参照の集合と、参照から到達可能なすべてのオブジェクトを含むオブジェクトデータベース。場合によっては、1つ以上のポーセリンからのメタデータが付属しています。リポジトリは、代替メカニズムを介して他のリポジトリとオブジェクトデータベースを共有できます。

失敗した自動マージが残したものを手動で修正するアクション。

コミット（名詞）の同義語。

開発の一部を破棄すること、つまりヘッドを以前のリビジョンに割り当てること。

ソースコード管理（ツール）。

「Secure Hash Algorithm 1」; 暗号学的ハッシュ関数。Git の文脈ではオブジェクト名の同義語として使用されます。

ほとんどシャローリポジトリの同義語ですが、この表現は git clone --depth=... コマンドを実行して作成されたことをより明確に示しています。

シャローリポジトリは不完全な履歴を持ち、そのコミットの中には親が切り捨てられているものがあります（言い換えれば、Gitはこれらのコミットには親がないと見せかけます。実際にはコミットオブジェクトに記録されているにもかかわらず）。これは、アップストリームに記録されている実際の履歴がはるかに大きい場合でも、プロジェクトの最近の履歴にのみ関心がある場合に役立つことがあります。シャローリポジトリはgit-clone[1]に--depthオプションを付けて作成され、その履歴は後でgit-fetch[1]で深めることができます。

ダーティな作業ディレクトリとインデックスの内容を一時的に保存し、将来再利用するためのオブジェクト。

別のリポジトリ（後者はスーパープロジェクトと呼ばれる）の中に、別のプロジェクトの履歴を保持するリポジトリ。

作業ツリー内に他のプロジェクトのリポジトリをサブモジュールとして参照するリポジトリ。スーパープロジェクトは、含まれるサブモジュールのコミットオブジェクトの名前を知っていますが（コピーは保持しません）。

SHA-1 ID そのものを含まず、ref: refs/some/thing の形式で、参照されるとこの参照を再帰的にデリファレンスする。HEAD がシンボリック参照の代表例。git-symbolic-ref[1] コマンドでシンボリック参照を操作する。

refs/tags/ 名前空間の下にある参照で、任意の型のオブジェクトを指します（通常、タグはタグまたはコミットオブジェクトのいずれかを指します）。ヘッドとは対照的に、タグはcommitコマンドによって更新されません。GitタグはLispタグ（Gitの文脈ではオブジェクト型と呼ばれるでしょう）とは関係ありません。タグは通常、コミット祖先チェーン内の特定のポイントをマークするために使用されます。

別のオブジェクトを指す参照を含み、コミットオブジェクトと同様にメッセージを含めることができるオブジェクト。PGP署名を含めることもでき、その場合は「署名付きタグオブジェクト」と呼ばれます。

開発者が概念的な開発ラインを識別するために使用する通常のGitブランチ。ブランチは非常に簡単で安価であるため、それぞれが非常によく定義された概念または小さな増分的だが関連する変更を含む複数の小さなブランチを持つことが望ましいことがよくあります。

キーと値のメタデータ。トレーラーはオプションでコミットメッセージの最後に記載されます。他のコミュニティでは「フッター」または「タグ」と呼ばれることもあります。git-interpret-trailers[1] を参照してください。

作業ツリー、または依存するブロブオブジェクトとツリーオブジェクトを含むツリーオブジェクト（つまり、作業ツリーの保存された表現）。

ファイル名とモードのリスト、および関連するブロブオブジェクトやツリーオブジェクトへの参照を含むオブジェクト。ツリーはディレクトリと同じです。

ツリーオブジェクト、またはツリーオブジェクトに再帰的にデリファレンスできるオブジェクト。コミットオブジェクトをデリファレンスすると、リビジョンの最上位ディレクトリに対応するツリーオブジェクトが得られます。以下のすべてがツリーっぽいものです：コミットっぽい、ツリーオブジェクト、ツリーオブジェクトを指すタグオブジェクト、ツリーオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。

HEADはまだ存在せず、まだコミットもされていないブランチを指すことができ、そのようなブランチは未作成ブランチと呼ばれます。ユーザーが未作成ブランチに遭遇する最も一般的な方法は、他の場所からクローンせずにリポジトリを新規作成することです。HEADは、まだ作成されていないmain（または構成によってはmaster）ブランチを指します。また、一部の操作ではorphanオプションを使用して未作成ブランチに入ることができます。

未マージのインデックスエントリを含むインデックス。

ブランチ、タグ、またはその他の参照から到達不能なオブジェクト。

問題のブランチにマージされる（または問題のブランチがリベースされる）デフォルトのブランチ。これは branch.<name>.remote と branch.<name>.merge で設定されます。A のアップストリームブランチが origin/B の場合、時々「A は origin/B を追跡している」と言います。

実際にチェックアウトされたファイルのツリー。作業ツリーには通常、HEADコミットのツリーの内容と、まだコミットしていないローカルの変更が含まれています。

リポジトリにはゼロ（ベアリポジトリの場合）または1つ以上のワークツリーがアタッチされています。1つの「ワークツリー」は、「作業ツリー」とリポジトリのメタデータで構成されており、そのほとんどは単一リポジトリの他のワークツリーと共有され、一部はワークツリーごとに個別に管理されます（例：インデックス、HEAD、MERGE_HEADのような疑似参照、ワークツリーごとの参照、ワークツリーごとの設定ファイル）。