Git
日本語 ▾ Topics ▾ Latest version ▾ gitglossary last updated in 2.44.0

NAME

gitglossary - Gitの用語集

概要

*

説明

代替オブジェクトデータベース (alternate object database)

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

ベア リポジトリ (bare repository)

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

ブロブオブジェクト(blob object)

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

ブランチ (branch)

A "branch" is a line of development. The most recent commit on a branch is referred to as the tip of that branch. The tip of the branch is referenced by a branch head, which moves forward as additional development is done on the branch. A single Git repository can track an arbitrary number of branches, but your working tree is associated with just one of them (the "current" or "checked out" branch), and HEAD points to that branch.

キャッシュ (cache)

廃止: インデックス

チェーン (chain)

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

チェンジセット (changeset)

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

チェックアウト (checkout)

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

チェリーピッキング (cherry-picking)

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

クリーン (clean)

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

コミット (commit)

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

動詞として。プロジェクト状態の新しいスナップショットを Git のヒストリーに保存することであり、 インデックス の現在の状態を表す新しいコミットを作成し、新しいコミットを指すように HEAD を進めます。

コミットグラフの概念、表現及び使い方

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

コミット‐グラフファイル (commit-graph file)

"コミットグラフ" ファイルは、コミットグラフのウォークを高速化するための コミットグラフ の補完的な表現です。"コミットグラフ" ファイルは、.git/objects/info ディレクトリまたは別のオブジェクトデータベースの info ディレクトリに格納されます。

コミットオブジェクト (commit object)

オブジェクト には、特定の リビジョン に関する情報、例えば やコミッター、著作者、日付、そして格納されているリビジョンの最上位 ディレクトリ と一致する ツリーオブジェクト を含みます。

コミットの性質を持つもの (commit-ish (also committish))

A commit object or an object that can be recursively dereferenced to a commit object. The following are all commit-ishes: a commit object, a tag object that points to a commit object, a tag object that points to a tag object that points to a commit object, etc.

core Git

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

DAG

有向非循環グラフ。親を持ち(有向)コミットオブジェクトのグラフは非循環なので、 コミットオブジェクト は有向非循環グラフを形成します(同じ オブジェクト で始まって終わる チェーン はありません)。

ダングリングオブジェクト (dangling object)

到達不能オブジェクト とは、他の到達不能オブジェクトからでさえも、 到達可能 ではないオブジェクトのことで、ダングリングオブジェクトは、 リポジトリ 内の参照や オブジェクト のいずれからも参照されないというものです。

dereference

Referring to a symbolic ref: the action of accessing the reference pointed at by a symbolic ref. Recursive dereferencing involves repeating the aforementioned process on the resulting ref until a non-symbolic reference is found.

Referring to a tag object: the action of accessing the object a tag points at. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified object type (where applicable) or any non-"tag" object type. A synonym for "recursive dereference" in the context of tags is "peel".

Referring to a commit object: the action of accessing the commit’s tree object. Commits cannot be dereferenced recursively.

Unless otherwise specified, "dereferencing" as it used in the context of Git commands or protocols is implicitly recursive.

分離したHEAD (detached HEAD)

通常、 HEAD には、ブランチ の名前が格納されており、HEADが示す履歴に対して操作するコマンドは、HEADが指すブランチの先端に続く履歴に対して操作することになります。しかし、Gitでは、必ずしも特定のブランチの先端ではない任意のコミットチェックアウト することもできます。このような状態のHEADは、"分離した (detached)"と呼ばれます。

現在のブランチの歴史を操作するコマンド(たとえば git commit で新しい歴史をその上に構築する)は、HEAD が分離されている間も動作することに注意してください。これらのコマンドは、どのブランチにも影響を与えずに HEAD を更新し、更新された歴史の先端を指すようにします。現在のブランチに関する情報を更新したり問い合わせたりするコマンド(たとえば 現在のブランチがどのリモート追跡ブランチと統合されているかを設定する git branch --set-upstream-to)は、この状態で尋ねる(実際の)現在のブランチがないため、明らかに機能しません。

ディレクトリ (directory)

"ls" で表示されるリスト :-)

ダーティ (dirty)

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

邪悪なマージ (evil merge)

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

早送り (fast-forward)

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

フェッチ (fetch)

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

ファイルシステム (file system)

リーナス・トーバルズはもともと、Gitをユーザー空間のファイルシステム、すなわち、ファイルとディレクトリを保持するためのインフラストラクチャとして設計しました。それによって、Gitの効率と速度が確保されました。

Git アーカイブ (Git archive)

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

gitファイル (gitfile)

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

移植 (grafts)

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

移植 の仕組みは時代遅れで、リポジトリ間でオブジェクトを転送する際に問題になる場合があることに注意してください。同じことを行うためのより柔軟で堅牢なシステムについては git-replace[1] をご覧ください。

ハッシュ (hash)

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

ヘッド (head)

A named reference to the commit at the tip of a branch. Heads are stored in a file in $GIT_DIR/refs/heads/ directory, except when using packed refs. (See git-pack-refs[1].)

HEAD

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

ヘッド参照 (head ref)

head と同義です。

フック (hook)

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

インデックス (index)

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

インデックスエントリー (index entry)

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

master

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

マージ (merge)

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

名詞として: 早送り でない限り、マージが成功すると、マージされた ブランチ の先端を として持つ、マージの結果を表す新しい コミット が作成されます。このコミットは、「マージコミット」、または単に「マージ」と呼ばれることもあります。

オブジェクト (object)

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

オブジェクトデータベース (object database)

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

オブジェクト識別子 (object identifier, oid)

object name と同義。

オブジェクト名 (object name)

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

オブジェクトタイプ (object type)

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

タコ足 (octopus)

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

孤児 (orphan)

The act of getting on a branch that does not exist yet (i.e., an unborn branch). After such an operation, the commit first created becomes a commit without a parent, starting a new history.

origin

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

オーバーレイ (overlay)

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

パック (pack)

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

パックインデックス (pack index)

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

パススペック (pathspec)

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

パススペック は、"git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout" やその他多くのコマンドで、操作範囲をツリーの一部やワーキングツリーに限定して使用するために使用するものです。パスがカレントディレクトリやトップレベルからの相対パスであるかどうかは、各コマンドのドキュメントを参照してください。パススペックの構文は次のとおりです。

  • すべてのパスが一致する

  • パススペックの最後のスラッシュまでの部分は、ディレクトリプレフィックスを表します。そのパススペックのスコープは、そのサブツリーに制限されます。

  • パススペックの残りの部分は、パス名の残りの部分のパターンです。ディレクトリプレフィックスに関連するパスは、fnmatch(3) を使用してそのパターンと照合されます。特に、「*」と「?」 はディレクトリセパレータに一致させることができます。

例えば、Documentation/*.jpg とすると、Documentation/chapter_1/figure_1.jpg を含む、Documentationサブツリーにあるすべての .jpg ファイルにマッチします。

コロン : で始まるパススペックは特別な意味を持ちます。短い形式では、先頭のコロン : の後に 0 個以上の「マジックシグネチャ」文字が続き (オプションで別のコロン : で終了します)、残りの部分がパスに対してマッチするパターンになります。「マジックシグネチャ」は英数字でもグロブでも正規表現の特殊文字でもコロンでもないASCIIシンボルで構成されます。「マジックシグネチャ」を終了するオプションのコロンは、「マジックシグネチャ」シンボルセットに属さず、かつコロンでもない文字でパターンが始まっている場合には省略することが可能です。

長い形式では、先頭のコロン : の後に、開き括弧 (, カンマで区切られた0個以上の「マジックワード」のリスト、閉じ括弧 ) が続き、残りがパスに対してマッチするパターンになります。

コロンのみのパス指定は、「パススペックがない」ことを意味します。この形式は他の パススペック と組み合わせてはいけません。

top

マジックワードの top (マジックシグネチャ: /) は、サブディレクトリの中からコマンドを実行した場合でも、ワーキングツリーのルートからパターンにマッチするようにします。

literal

パターン中の *? などのワイルドカードは、リテラル文字として扱われます。

icase

大文字・小文字を区別せずマッチ。

glob

Git はこのパターンを、FNM_PATHNAME フラグを指定した fnmatch(3) に適したシェルグロブとして扱います。パターン中のワイルドカードは、パス名中の / にはマッチしません。例えば、"Documentation/*.html" は "Documentation/git.html" にマッチしますが、"Documentation/ppc/ppc.html" や "tools/perf/Documentation/perf.html" にはマッチしません。

2つ連続したアスタリスク("**")はフルパス名に対してマッチするパターンにおいて、特別な意味を持つ場合があります:

  • 先頭の "**/" は、すべてのディレクトリにマッチすることを意味します。例えば、"**/foo" はファイルまたはディレクトリ "foo" の任意の場所にマッチし、パターン "foo" と同じです。 "**/foo/bar" はファイルまたはディレクトリ "bar" がディレクトリ "foo" 直下の任意の場所にある場合にマッチします。

  • 末尾の "/**" は、その中にあるすべてのファイルにマッチします。例えば、"abc/**" はディレクトリ "abc" 内のすべてのファイルにマッチします。これは .gitignore ファイルの位置からの相対パスで、深さは無限です。

  • 末尾以外での "/**" は、0個以上のディレクトリにマッチします。例えば、"a/**/b" は "a/b", "a/x/b", "a/x/y/b" といった具合にマッチする。

  • これら以外の連続したアスタリスクは無効とする。

    グロブの魔法は魔法と互換性がありません。

attr

attr: の後にはスペースで区切られた「属性要件」のリストが続き、パスがマッチしたとみなされるためには、これらの要件がすべて満たされなければなりません。これは、普通の魔法のないパススペック パターン マッチングに追加されます。gitattributes[5]を参照してください。

パスの各属性要件は、これらのいずれかの形式をとる:

  • "ATTR" は、属性 ATTR を設定することを要求します。

  • "-ATTR" は、属性 ATTR の設定を解除することを要求しています。

  • "ATTR=VALUE" は、属性 ATTR に文字列 VALUE を設定することを要求しています。

  • "!ATTR" は、属性 ATTR が指定されていないことを要求しています。

    ツリーオブジェクトに対してマッチングを行う場合、属性は与えられたツリーオブジェクトからではなく、ワーキングツリーから取得されることに注意してください。

exclude

パスが何らかの非除外パススペックにマッチした後、すべての除外パススペック (マジックシグネチャ: ! またはその同義語 ^) を通して実行されることになります。マッチした場合、そのパスは無視されます。非除外パススペックがない場合は、パススペックなしで起動された場合と同じように、結果セットに除外が適用されます。

親 (parent)

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

皮を剥く (peel)

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

つるはし (pickaxe)

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

配管 (plumbing)

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

磁器 (porcelain)

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

ワークツリーごとの参照 (per-worktree ref)

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

疑似参照 (pseudoref)

疑似参照は $GIT_DIR 以下にあるファイルの類で、rev-parse の目的では refs のように振る舞いますが、git では特別に扱われるものです。疑似参照はいずれも大文字の名前を持ち、常に SHA-1 と空白文字からなる行で始まります。つまり、HEADはシンボリック参照となる場合もあるので、疑似参照ではありません。それらはオプションでいくつかの追加データを含むかもしれません。 MERGE_HEADCHERRY_PICK_HEAD がその例になります。 ワークツリーごとの参照 とは異なり、これらのファイルはシンボリック参照にはなりえず、参照ログも持ちえません。また、通常の参照の更新機構によって更新されることもありません。代わりに、ファイルに直接書き込むことによって更新されます。しかし、これらはあたかも参照であるかのように読むことができるので、 git rev-parse MERGE_HEAD は動作します。

プル (pull)

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

プッシュ (push)

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

到達可能 (reachable)

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

到達可能性ビットマップ (reachability bitmaps)

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

リベース (rebase)

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

参照(ref)

refs/`で始まる名前(例えば `refs/heads/master)は、オブジェクト名または別の参照(後者はシンボリック参照と呼ばれる)を指します。便宜上、参照はGitコマンドの引数として使用する際に時々省略されることがあります。詳細は gitrevisions[7] を参照してください。参照はリポジトリに格納されます。

参照の名前空間は階層的です。異なる目的に応じて異なるサブ階層が使用されます(例えば、refs/heads/ 階層はローカルブランチを表すために使用されます)。

refs/`で始まらない特別な目的の参照がいくつかあります。最も分かりやすい例は `HEAD です。

参照ログ(reflog)

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

参照スペック(refspec)

「参照スペック」はフェッチおよびプッシュによって使用され、リモートの参照とローカル参照の間のマッピングを記述します。

リモートリポジトリ (remote repository)

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

リモートトラッキングブランチ (remote-tracking branch)

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

リポジトリ(repository)

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

解決 (resolve)

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

リビジョン(revision)

commit (名詞) と同義です。

巻き戻し (rewind)

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

SCM

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

SHA-1

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

シャロークローン (shallow clone)

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

シャローリポジトリ (shallow repository)

シャローリポジトリは、不完全な履歴を持ち、その中のいくつかのコミットが切り取られています(言い換えると、これらのコミットがコミットオブジェクトに記録されているにも関わらず、Gitはこれらのコミットが親を持たないかのように振る舞うよう指示されています)。これは、プロジェクトの最近の履歴にのみ興味がある場合に便利ですが、実際の履歴はアップストリームにもっと大きく記録されている場合があります。シャローリポジトリは、 git-clone[1] に`--depth`オプションを与えることで作成され、後に git-fetch[1] を使って履歴を深めることができます。

スタッシュエントリー (stash entry)

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

特殊な参照 (special ref)

通常の参照と異なるセマンティクスを持つ参照。これらの参照は通常のGitコマンドでアクセスできますが、場合によって通常の参照と同じ挙動をしないケースがあります。

以下の特殊な参照がGitでは知られています:

  • "FETCH_HEAD" is written by git-fetch[1] or git-pull[1]. It may refer to multiple object IDs. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status.

  • "MERGE_HEAD" is written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.

サブモジュール (submodule)

別のリポジトリ(親プロジェクトと呼ばれます)の中で分離されたプロジェクトの履歴を保持するリポジトリです。

親プロジェクト (superproject)

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

シンボリック参照 (symref)

シンボリック参照: SHA-1 ID自体を含むのではなく ref: refs/some/thing’という形式をとり、参照されると再帰的に 参照外し をします。HEAD'はシンボリック参照の主な例です。シンボリック参照は git-symbolic-ref[1] コマンドで操作されます。

タグ (tag)

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

タグオブジェクト (tag object)

他のオブジェクトを指す参照を含むオブジェクトで、コミットオブジェクトのようにメッセージを含むことができます。また、(PGPの)署名を含む場合は、「署名付きタグオブジェクト」と呼ばれます。

トピックブランチ(topic branch)

開発者が開発の概念的な流れを識別するために使用する通常のGitブランチです。ブランチは非常に簡単かつ安価であるため、非常に明確に定義された概念のものや 小さく少しずつ進めた関連する変更を含むもの などの小さなブランチをいくつか持つことが望ましいです。

ツリー (tree)

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

ツリーオブジェクト (tree object)

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

ツリーの性質を持つもの (tree-ish (also treeish))

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

胎児 (unborn)

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.

マージされていないインデックス (unmerged index)

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

到達不能オブジェクト (unreachable object)

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

上流ブランチ(upstream branch)

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

作業ツリー (working tree)

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

ワークツリー (worktree)

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

GIT

Part of the git[1] suite

scroll-to-top