gitglossary(7) Manual Page

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

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

型の無いオブジェクト。例:ファイルの中身。

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

廃止。 index を使ってください。

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

"コミット" の BitKeeper/cvsps での言い方です。 Git は変更(change)ではなく状態(state)を保存するため、Gitでコミットを「changeset」と呼ぶのはナンセンスです。

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

SCM の専門用語では、 "cherry pick" (つまみ食い)とは、一連の変更(通常はコミット)から変更のサブセットを選択し、それらを別のコードベースの上に新しい一連の変更として記録することを意味します。 Git では、 これは git cherry-pick コマンドを使用して、 既存のコミットによって導入された変更を抽出し、 それを現在のブランチの先端に新しいコミットとして記録することによって行われます。

現在のヘッドが参照するリビジョンと作業ツリーが完全に一致(correspond)しているのであれば、その作業ツリーはクリーンです。「dirty」も参照下さい。

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

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

"commit-graph" という(通常はハイフンでつながれたファイル名の)ファイルは、 コミット・グラフ・ウォークを高速化する commit chart の補足表現です。 "commit-graph" ファイルは、 .git/objects/info ディレクトリまたは代替オブジェクト・データベースの info ディレクトリに保存されます。

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

コミット・オブジェクト、 またはコミット・オブジェクトに対して再帰的に逆参照できるオブジェクト。 コミットオブジェクトや、コミットオブジェクトを指すタグオブジェクトや、コミットオブジェクトを指すタグオブジェクトを指すタグオブジェクトなどは全てcommit-ish(commit-ishes)です。

Gitの基本的なデータ構造とユーティリティ。これは、限定的なソースコード管理ツールのみです。

有向非巡回グラフ(Directed acyclic graph)。 コミットオブジェクト は、(有向の)親を持ち、コミットオブジェクトのグラフが非巡回(同じ オブジェクト で開始・終了する チェイン はありません)であるため有向非巡回グラフを形成します。

(ぶらぶら揺れるオブジェクト)他の到達不能オブジェクトからでも到達できない到達不能オブジェクト。 danglingオブジェクトには、リポジトリ内の任意のrefまたはオブジェクトからの参照はありません。

シンボリック ref(symbolic ref) の参照: シンボリック ref が指す 参照 にアクセスするアクション。 再帰逆参照(recursive dereferencing)では、 非シンボリック参照が見つかるまで、 結果の ref に対して従前のプロセスを繰り返します。

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

あなたが "ls" で得られる一覧の事 :-)

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

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

fast-forward(早送り)は、とあるリビジョンに、その子孫である別のブランチの変更をマージする特殊なタイプのマージです。このような場合、新しいマージコミットを行うのではなく、マージするブランチと同じリビジョンを指すようにブランチを更新するだけです。これは、リモートリポジトリのリモート追跡ブランチで頻繁に発生します。

ブランチをフェッチするということは、リモートリポジトリからブランチのhead refを取得して、ローカルのオブジェクトデータベースに欠落しているオブジェクトを見つけ、そして欠落したオブジェクトを取得することを意味します。 git-fetch(1) も参照してください。

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

リポジトリ の同義語(arch people 向け)。

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

graftsは、コミットの偽の祖先情報を記録することで、他の点では異なる2つの開発ラインを結合できます。こうすることで、あるコミットが持つ親の組を、コミット作成時に記録されたものとは異なるものとして Git に見せかけることができるのです。これは .git/info/grafts ファイルを介して構成されます。

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

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

現在のブランチ。 より詳細に言うと、あなたの作業ツリーは通常、HEADによって参照されるツリーの状態から派生します。HEADは、リポジトリ内のhead達のうちの一つへの参照です。ただし、detached HEADの場合は、任意のコミットを直接参照しています。

head の同義語。

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

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

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

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

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

Gitの保管ユニット(unit of storage)。その内容による SHA-1 によって一意に識別されます。したがって、オブジェクトを変更することはできません。

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

object name (オブジェクト名)の同義語

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

オブジェクトのタイプを表すもので、 "commit" または "tree" または "tag" または "blob" のいずれかです。

3つ以上(more than two)のブランチをマージします

まだ存在しない ブランチ (つまり、unborn ブランチ)を得るアクション。 このような操作の後、 最初に作成されたコミットは親のないコミットになり、 新しい履歴(new history)の開始点となります。

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

cp -R が宛先ディレクトリの内容を更新するのと同様に、ファイルを更新して作業ディレクトリに追加するのみで削除を行いません。これは、インデックスまたはツリー風の何か(tree-ish)からファイルをチェックアウトするときのcheckoutのデフォルトモードです。対照的に、オーバーレイなしモード(no-overlay mode)では、 rsync --delete と同様に、ソース側に存在しない追跡ファイルは削除されます。

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

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

(パススペック):Gitコマンドでパスを制限するために使用されるパターン。

コミットオブジェクトには、開発ラインで論理的に前にあったもののリスト、つまり親が含まれています(あるいは、前・親が無い場合は空です)。

逆参照(dereferencing) を tag object に対して再帰的に実行するアクション。

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

core Git のキュートな呼び方。

core Gitに依存するプログラムとプログラムスイートのキュートな名前で、コアGitへの高レベルのアクセスを示します。磁器(porcelain)は、配管(plumbing)よりも多くのSCMインターフェースを公開します。

グローバルではなく、 worktreeごとのref。これは現在、HEADと refs/bisect/ で始まるすべてのrefのみですが、今後、他の普通でないrefが含まれる可能性があります。

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

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

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

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

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

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

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

reflogは、refのローカルの「履歴」を示します。 つまり、このリポジトリの最後の3番目のリビジョンが何であったか、およびこのリポジトリの昨日の午後9時14分時点での「現在の状態」が何であったかを知ることができます。詳細については git-reflog(1) を参照してください。

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

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

別のリポジトリからの変更を追跡するために使用されるref。 これは通常、 refs/remotes/foo/bar のように見え(「foo」という名前のリモートで「bar」という名前のブランチを追跡することを示します)、構成されたフェッチrefspecの右側(right-hand-side)に一致します。リモート追跡ブランチには、直接の変更を含めたり、ローカルコミットを行ったりしないでください。

refsのコレクションと、refから到達可能なすべてのオブジェクトを含むオブジェクト・データベース。1つまたは複数の磁器コマンドからのメタ・データが付随している可能性があります。リポジトリは、代替メカニズムを介してオブジェクト・データベースを他のリポジトリと共有できます。

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

コミット (名詞) の同義語

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

Source code management (tool).

セキュアハッシュアルゴリズム1(Secure Hash Algorithm 1);暗号化ハッシュ関数。 Git界隈ではオブジェクト名の同義語として使用されます。

ほとんどの場合 shallowリポジトリ の同義語ですが、この言い方は、 git clone --depth=... コマンドを実行して作成されたこと明言したものです。

浅いリポジトリ(shallow repository)には不完全な履歴があり、そのコミットの一部では親が削除されて(cauterized away)います(言い換えると、Gitは、コミットオブジェクトに記録があっても、これらのコミットには親がないふりをするように指示されます)。これは、アップストリームで記録された実際の履歴がはるかに大きい場合でも、プロジェクトの最近の履歴のみに関心がある場合に役立つことがあります。浅いリポジトリは、 git-clone(1) に --depth オプションを指定することで作成され、その履歴は後で git-fetch(1) で深めることができます。

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

とあるリポジトリの内部で、それとは別個のプロジェクトの履歴を保持する リポジトリ (ここで、その、とあるリポジトリを スーパープロジェクト と呼びます)。

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

シンボリック参照(symbolic reference): SHA-1 ID自体を含む代わりに「ref: refs/some/thing」の形式であり、参照されると、この参照を再帰的に逆参照(dereferences)します。 HEAD はsymrefの代表的な例です。シンボリックrefは git-symbolic-ref(1) コマンドで操作されます。

任意のタイプのオブジェクトを指す refs/tags/ 名前空間の下のref(通常、タグは タグ または コミットオブジェクト のいずれかを指します)。headとは対照的に、タグは commit コマンドによって更新されません。Gitタグは、Lispタグとは何の関係もありません(Git界隈では、それはオブジェクトタイプと呼ばれます)。タグは通常、コミットの祖先チェーンの特定のポイントをマークするために使用されます。

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

開発者が概念的な開発ラインを識別するために使用する通常のGitブランチ。(従来のSCMに比べて)ブランチは非常に簡単で処理コストが掛からないため、それぞれが非常に明確に定義された概念または小さな増分であるが関連する変更を含む、いくつかの小さなブランチを持つことが望ましい場合がよくあります。

Key-value メタデータ。 トレーラーは、 コミット・メッセージの最後にオプションで表示されます。 他のコミュニティでは「フッター」とか「タグ」と呼ばれる場合があります。 git-interpret-trailers(1) を参照してください。

作業ツリー、または、ツリーオブジェクトとそれに依存するブロブやツリーオブジェクト(つまり、作業ツリーの保存された表現)、のいずれか。

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

ツリーっぽい何か。ツリーオブジェクトに再帰的に逆参照(dereferenced)できる ツリーオブジェクト または オブジェクト です。 コミットオブジェクト を逆参照すると、その リビジョン の最上位 ディレクトリ に対応するツリーオブジェクトが生成されます。※これら(右記)は全てツリーっぽい(tree-ish)何かです: <コミットっぽい何か、 ツリー・オブジェクト、 ツリーオブジェクトを指すタグ・オブジェクト、 タグ・オブジェクトを指すタグ・オブジェクト。

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

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

ブランチ または タグ またはその他の参照から 到達可能 ではない(辿れない、ポイントされてない) オブジェクト 。

当該のブランチからマージされる(または当該のブランチがリベースされる)デフォルトのブランチ。これは、 branch.<name>.remote や branch.<name>.merge を介して構成されます。Aのアップストリームブランチが origin/B の場合、「Aは origin/B を追跡しています」と言うことがあります。

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

リポジトリには、ゼロ(ベア・リポジトリ)または1つ以上の worktree を当てはめる(attach)ことができます。 1 つの「worktree」は「作業ツリー」(working tree)とリポジトリ・メタデータで構成され、 そのほとんどは単一のリポジトリの他の worktree 間で共有され、一部は worktree ごとに個別に維持されます(例: インデックスやHEADやMERGE_HEADなどの疑似ref(pseudorefs)、worktreeごとの ref や worktree ごとの構成ファイル)。