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

ベアリポジトリは通常、適切な名前のディレクトリで、`.git` サフィックスを持ち、バージョン管理下のファイルのローカルチェックアウトコピーがありません。つまり、通常は隠し`.git` サブディレクトリにあるすべてのGit管理ファイルと制御ファイルは、代わりに`repository.git` ディレクトリに直接存在し、他のファイルは存在せず、チェックアウトされていません。通常、公開リポジトリの発行者はベアリポジトリを提供します。

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

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

インデックスに対して廃止。

オブジェクトのリストで、リスト内の各オブジェクトには、その次のオブジェクトへの参照が含まれています（たとえば、コミットの次のオブジェクトは、その親の1つになる可能性があります）。

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

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

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

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

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

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

「commit-graph」（通常はハイフン付き）ファイルは、コミットグラフの補足的な表現であり、コミットグラフのウォークを高速化します。「commit-graph」ファイルは、.git/objects/infoディレクトリまたは代替オブジェクトデータベースのinfoディレクトリに格納されます。

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

コミットオブジェクトまたは再帰的に逆参照してコミットオブジェクトにすることができるオブジェクト。以下はすべてコミット-ishです。コミットオブジェクト、コミットオブジェクトを指すタグオブジェクト、コミットオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。

Gitの基本的なデータ構造とユーティリティ。ソースコード管理ツールは限定的にしか公開していません。

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

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

シンボリック参照を参照する場合：シンボリック参照によって指される参照にアクセスする操作。再帰的な逆参照には、非シンボリック参照が見つかるまで、結果の参照に対して前述のプロセスを繰り返すことが含まれます。

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

"ls"で取得できるリスト :-)

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

不正なマージとは、いずれの親にも表示されない変更を導入するマージです。

高速フォワードは、リビジョンがあり、現在持っているリビジョンの子孫である別のブランチの変更を「マージ」する特殊なタイプのマージです。このような場合、新しいマージコミットを作成するのではなく、マージしているブランチと同じリビジョンを指すようにブランチを更新します。これは、リモートリポジトリのリモート追跡ブランチで頻繁に発生します。

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

Linus Torvaldsは当初、Gitをユーザースペースファイルシステム、つまりファイルとディレクトリを保持するためのインフラストラクチャとして設計しました。これにより、Gitの効率性と速度が確保されました。

(アーカイバの人々にとって)リポジトリの同義語。

作業ツリーのルートにあるプレーンファイル.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とも呼ばれます。

オブジェクトのタイプを表す識別子「コミット」、「ツリー」、「タグ」、「ブロブ」のいずれか。

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

まだ存在しないブランチ(つまり、未生成のブランチ)に移動すること。このような操作の後、最初に作成されたコミットは親のないコミットになり、新しい履歴が始まります。

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

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

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

パック内のオブジェクトの識別子とその他の情報の一覧で、パックの内容に効率的にアクセスするのに役立ちます。

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

コミットオブジェクトには、開発ラインにおける論理的な先行オブジェクト（親）のリスト（空の場合もある）が含まれています。

タグオブジェクトを再帰的に逆参照する処理。

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

コアGitのかわいい名前。

コアGitに依存するプログラムとプログラムスイートのかわいい名前で、コアGitへの高レベルアクセスを提供します。Porcelainは、plumbingよりもSCMインターフェースを多く公開します。

グローバルではなく、作業ツリーごとの参照。現時点では、HEADとrefs/bisect/で始まる参照のみですが、後で他の特殊な参照が含まれる可能性があります。

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

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

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

指定されたコミットのすべての祖先は、そのコミットから「到達可能」であると言われます。より一般的には、タグをタグ付けされているものに、コミットをその親またはツリーに、ツリーをそれらが含むツリーまたはブロブにたどるチェーンによって、一方のオブジェクトからもう一方のオブジェクトに到達できる場合、一方のオブジェクトは他方から到達可能です。

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

ブランチから異なるベースに一連の変更を再適用し、そのブランチのヘッドを結果にリセットします。

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

reflogは、参照のローカル「履歴」を示します。つまり、このリポジトリの3番目に古いリビジョンが何であったか、そして昨日の午後9時14分にこのリポジトリの現在の状態がどうであったかを教えてくれます。詳細については、git-reflog[1]を参照してください。

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

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

別のリポジトリからの変更を追跡するために使用される参照。通常、refs/remotes/foo/barのように見えます（リモート名fooにあるbarという名前のブランチを追跡していることを示しています）。これは、構成されたフェッチrefspecの右側と一致します。リモート追跡ブランチには、直接的な変更を含めたり、ローカルコミットを作成したりしないでください。

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

自動的なマージが失敗した際に残された問題を手動で解決すること。

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

開発の一部を破棄すること、つまりHEADを以前のリビジョンに設定すること。

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

"Secure Hash Algorithm 1"；暗号学的ハッシュ関数。Gitのコンテキストではオブジェクト名の同義語として使用される。

ほとんどの場合浅いリポジトリの同義語だが、この語句を使用することで`git clone --depth=...`コマンドによって作成されたものであることがより明確になる。

浅いリポジトリは、不完全な履歴を持ち、その一部のコミットの親が切り離されている（言い換えれば、これらのコミットには親が存在しないとGitに伝えられる。たとえそれらがコミットオブジェクトに記録されているとしても）。これは、実際の履歴が上流でより大きく記録されている場合でも、プロジェクトの最近の履歴のみに興味がある場合に役立つことがある。浅いリポジトリはgit-clone[1]に`--depth`オプションを指定して作成され、その履歴は後でgit-fetch[1]で深めることができる。

オブジェクトを使用して、将来の再利用のために、変更が加えられた作業ディレクトリとインデックスの内容を一時的に保存する。

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

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

シンボリック参照：SHA-1 ID自体を含まない代わりに、`ref: refs/some/thing`という形式で、参照されると、この参照に再帰的にデリファレンスされる。HEADはsymrefの代表的な例である。シンボリック参照はgit-symbolic-ref[1]コマンドで操作される。

`refs/tags/`名前空間の下にあるrefで、任意のタイプのオブジェクトを指す（通常、タグはタグオブジェクトまたはコミットオブジェクトを指す）。ヘッドとは異なり、タグは`commit`コマンドによって更新されない。GitのタグはLispのタグとは関係ない（Gitのコンテキストではオブジェクトタイプと呼ばれる）。タグは、コミットの祖先のチェーン内の特定の点をマークするために最も一般的に使用される。

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

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

作業ツリー、またはツリーオブジェクトと依存するblobおよびツリーオブジェクト（つまり、作業ツリーの保存された表現）。

オブジェクトで、ファイル名とモードのリストと、関連付けられたblobおよび/またはツリーオブジェクトへのrefが含まれる。ツリーはディレクトリに相当する。

ツリーオブジェクトまたはオブジェクトで、再帰的にデリファレンスしてツリーオブジェクトにすることができる。コミットオブジェクトのデリファレンスは、リビジョンの最上位ディレクトリに対応するツリーオブジェクトを生成する。以下はすべてtree-ishである。commit-ish、ツリーオブジェクト、ツリーオブジェクトを指すタグオブジェクト、ツリーオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。

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

マージされていないインデックスエントリを含むインデックス。

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

対象のブランチにマージされる（または対象のブランチがリベースされる）デフォルトのブランチ。branch.<name>.remoteとbranch.<name>.mergeで設定される。Aの上流ブランチがorigin/Bの場合、時々「Aはorigin/Bをトラッキングしている」と言う。

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

リポジトリには、0個（つまり、ベアリポジトリ）または1個以上のworktreeを接続できる。1つの「worktree」は「working tree」とリポジトリのメタデータで構成され、そのほとんどは単一のリポジトリの他のworktree間で共有され、その一部はworktreeごとに個別に維持される（例：インデックス、HEAD、MERGE_HEADなどの擬似参照、worktreeごとの参照、worktreeごとの構成ファイル）。