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

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

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

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

以下のために廃止されました: インデックス。

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

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

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

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

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

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

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

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

特定のリビジョンに関する情報、例えば親、コミッター、作者、日付、そして保存されたリビジョンの最上位ディレクトリに対応するツリーオブジェクトを含むオブジェクト。

コミットオブジェクト、またはコミットオブジェクトに再帰的にデリファレンスできるオブジェクト。以下はすべてコミットイッシュです: コミットオブジェクト、コミットオブジェクトを指すタグオブジェクト、コミットオブジェクトを指すタグオブジェクトを指すタグオブジェクト、など。

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

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

他の到達不能なオブジェクトからも到達可能ではない到達不能なオブジェクト。リポジトリ内のどの参照やオブジェクトからも参照されていないオブジェクト。

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

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

「ls」コマンドで得られるリストです :-)

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

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

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

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

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

リポジトリの同義語（archの人向け）。

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

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

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

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

現在のブランチ。詳細には: あなたのワーキングツリーは通常、HEADが参照するツリーの状態から派生します。HEADは、detached HEADを使用する場合を除き、あなたのリポジトリ内のヘッドのいずれかへの参照であり、その場合は任意のコミットを直接参照します。

ヘッドの同義語。

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

stat情報を持つファイルのコレクションで、その内容はオブジェクトとして格納されます。インデックスはあなたのワーキングツリーの保存されたバージョンです。実のところ、インデックスはワーキングツリーの2番目、さらには3番目のバージョンも含むことができ、これらはマージ時に使用されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コアGitの愛称。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

失敗した自動マージが残したものを手動で修正する操作。

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

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

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

「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のような擬似参照、ワークツリーごとの参照、ワークツリーごとの設定ファイル）。