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

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

非定型の オブジェクト 例：ファイルの内容など。

「ブランチ」とは、開発ラインのことです。あるブランチにおける最新の コミット をブランチの先端と呼びます。ブランチの先端はブランチ・ ヘッド によって参照され、ブランチ上で開発が進むにつれて前に移動します。Git リポジトリ は任意の数のブランチを監視することができますが、 ワーキングツリー が関連付けられているのはそのうちの一つ（現在のブランチ、またはチェックアウトされているブランチ）のみであり、 HEAD はそのブランチを指します。

廃止: インデックス。

オブジェクトのリストで、リスト内の各 オブジェクト はその後継者への参照を含みます（例えば、コミット の後継者はその 親 になる可能性があります）。

BitKeeper/cvsps が "コミット" に代えて呼ぶものです。Gitは変更を保存するのではなく、状態を保存するので、Gitで "チェンジセット" という用語を使うのは本当に意味がありません。

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

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

ワーキングツリー が、現在の ヘッド が参照する リビジョン に合致する場合、クリーンである。また、 "ダーティ" も参照してください。

名詞として。プロジェクトのヒストリー全体は、相互に関連するコミットの集合として表されます。Gitでは、他のリビジョン管理システムが "リビジョン" や "バージョン" という言葉を使うのと同じ場所で、"コミット" という言葉が使われることがよくあります。また、 コミットオブジェクト のショートハンドとしても使われます。

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

"コミットグラフ" ファイルは、コミットグラフのウォークを高速化するための コミットグラフ の補完的な表現です。"コミットグラフ" ファイルは、.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] を参照してください。

移植を使用すると、コミットの偽の祖先情報を記録することで、2つの異なる開発ラインを結合できます。このようにして、Gitに コミット の 親 のセット が、コミットが作成されたときに記録したものとは異なるというふりをさせることができます。 .git/info/grafts ファイルを介して構成されます。

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

名前を付けて参照する ブランチ の先端にある コミット のことです。ヘッダは、パックされた参照を使うとき以外は、 $GIT_DIR/refs/heads/ ディレクトリにあるファイルに格納されます。(git-pack-refs[1] を参照してください。)

現在の branch。詳細: ワーキングツリー は通常、HEADによって参照されるツリーの状態から派生します。HEADはリポジトリ内の ヘッド の1つを参照するものですが、 分離したHEAD を使用する場合は、任意のコミットを直接参照します。

head と同義です。

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

統計情報を含むファイルのコレクションで、その内容はオブジェクトとして保存されます。インデックスは、 ワーキングツリー の保存バージョンです。正直なところ、これには、 マージ のときに使用される、ワーキングツリーの2番目および3番目のバージョンを含めることもできます。

インデックス に保存されている特定のファイルに関する情報。 マージ が開始されたが、まだ終了していない場合（つまり、インデックスにそのファイルの複数のバージョンが含まれている場合）、インデックスエントリーをマージ解除できます。

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

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

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

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

object name と同義。

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

識別子 "コミット", "ツリー", "タグ" または "ブロブ" のいずれかでもって、 オブジェクト のタイプを表します。

2つより多くの ブランチ を マージ する。

まだ存在しない branch (つまり、unborn ブランチ) にアクセスする操作。このような操作の後、最初に作成されたコミットは親のないコミットになり、新しい履歴が開始されます。

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

作業ディレクトリへのファイルの更新と追加のみを行う一方で削除は行わない、 cp -R が宛先ディレクトリの内容を更新するのと同様の方法です。これは、チェックアウト が インデックス や ツリーの性質を持つものからファイルをチェックアウトするときにおけるデフォルトモードです。一方、非オーバーレイ モードでは、 rsync --delete のように、ソースに存在しない追跡済みのファイルも削除されます。

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

パックの中身への効率よいアクセスを補助する、 パック にあるオブジェクトの識別子やその他の情報のリストです。

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

コミットオブジェクト は、開発ラインにおける論理的な先行者、すなわちその親の (空かもしれない) リストを含んでいます。

再帰的に タグオブジェクト の 逆参照する 動作のこと。

つるはし という用語は、与えられたテキスト文字列を追加または削除する変更を選択するのに役立つ diffcore ルーチンのオプションのことを指します。 --pickaxe-all オプションを使うと、例えば特定の行を追加したり削除したりした チェンジセット をすべて表示することができます。git-diff[1] を参照してください。

core Gitのかわいい名前です。

core Gitに依存するプログラムやプログラムスイートのかわいい名前で、core Gitへのハイレベルなアクセスを提示します。磁器は 配管 よりも多くの SCM インタフェースを公開します。

グローバルではなく、ワークツリーごとの参照。現在は HEAD と refs/bisect/ で始まる参照のみですが、将来的には他の珍しい参照も含まれるかもしれません。

A ref that has different semantics than normal refs. These refs can be read via normal Git commands, but cannot be written to by commands like git-update-ref[1].

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

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

特定のコミットのすべての祖先は、そのコミットから「到達可能」と言われます。より一般的には、一つのオブジェクトが別のオブジェクトから到達可能であるとは、我々がその他のオブジェクトから一つのオブジェクトにチェーンをたどって到達できる場合を指し、タグからタグ付けている何か、コミットからその親またはツリー、そしてツリーから内包するツリーやブロブをたどって到達することです。

到達可能性ビットマップは、パックファイルやマルチパックインデックス（MIDX）における選択されたコミット群の到達可能性に関する情報を格納し、オブジェクト検索を速めるために使用されます。ビットマップは ".bitmap" ファイルに格納されます。リポジトリは最大で一つのビットマップファイルを使用できます。ビットマップファイルは、単一のパックに属しているか、またはリポジトリのマルチパックインデックス（存在する場合）に属しているかのどちらかです。

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

A name that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository.

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

A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref. See git-fetch[1] or git-push[1] for details.

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

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

参照の集まりと、参照から到達可能なすべてのオブジェクトを含むオブジェクトデータベースで構成されたコレクションで、これには一つまたは複数の磁器からのメタデータが付随することもあります。リポジトリは代替の仕組みを通じて他のリポジトリとオブジェクトデータベースを共有することができます。

失敗した自動的な マージ が残したものを手動で修正する行為。

commit (名詞) と同義です。

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

ソースコードマネジメント(ツール).

"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ブランチです。ブランチは非常に簡単かつ安価であるため、非常に明確に定義された概念のものや 小さく少しずつ進めた関連する変更を含むもの などの小さなブランチをいくつか持つことが望ましいです。

ワーキングツリー または、 ツリーオブジェクト のどちらかと、それに従属する ブロブ およびツリーオブジェクト（つまりワーキングツリーの保存された表現）である。

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

ツリーオブジェクトを再帰的に 逆参照 できる ツリーオブジェクト または オブジェクト 。コミッオブジェクト の参照先を展開すると、 リビジョン の最上位 ディレクトリ に対応するツリーオブジェクトが生成されます。以下はすべてツリーの性質を持つものです: コミットの性質を持つもの、 ツリーオブジェクト、ツリーオブジェクトを指す タグオブジェクト 、ツリーオブジェクトを指すタグオブジェクトを指すタグオブジェクトなど。

The HEAD can point at a branch that does not yet exist and that does not have any commit on it yet, and such a branch is called an unborn branch. The most typical way users encounter an unborn branch is by creating a repository anew without cloning from elsewhere. The HEAD would point at the main (or master, depending on your configuration) branch that is yet to be born. Also some operations can get you on an unborn branch with their orphan option.

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

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

問題の中でブランチにマージされる（またはそのブランチがリベースされる）デフォルトのブランチです。これはbranch.<名前>.remoteとbranch.<名前>.mergeを通じて設定されます。'A’の上流ブランチが’origin/B’である場合、「'A’は’origin/B’をトラッキングしている」と言うことがあります。

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

リポジトリは、ゼロ（すなわちベアリポジトリ）または一つ以上のワークツリーを持つことができます。一つの「ワークツリー」は、「作業ツリー」とリポジトリのメタデータで構成され、その大部分は単一リポジトリの他のワークツリー間で共有され、一部はワークツリーごとに個別に保持されます（例えば、インデックス、HEAD、MERGE_HEADのような疑似参照、ワークツリーごとの参照やワークツリーごとの設定ファイルなど）。