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構造の同義語。 この構造はコミット・グラフの決定版です。 グラフはたとえば "commit-graph" file のように他の方法でも表現できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実際のリポジトリであるディレクトリを指す、作業ツリーのルートにあるプレーンファイル .git

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進文字列で表されます。一般に <<def_SHA1 とも呼ばれます。

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

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

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

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

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

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

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

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

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

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

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

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

疑似参照(pseudoref)は $GIT_DIR の下にあるファイルのクラスであり、rev-parseしたときrefのように動作しますが、それはgitによって特別扱されます。疑似参照はすべて大文字の名前を持ち、かつ、常にSHA-1とそれに続く空白(whitespace)で構成される行で始まります。したがって、HEADは疑似参照ではありません。なぜならHEADはシンボリック参照である場合があるためです。オプションで、いくつかの追加データが含まれる場合があります。例としては MERGE_HEAD と CHERRY_PICK_HEAD があります。 per-worktree refs とは異なり、これらのファイルはシンボリックrefにすることはできず、reflogを含めることはできません。 また、通常のref更新機構を使用して更新することもできません。代わりに、ファイルに直接書き込むことによって更新されます。ただし、それらはrefであるかのように読み取ることができるため、 git rev-parse MERGE_HEAD は機能します。

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

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

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

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

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

オブジェクト名または別のrefを指す refs/ で始まる名前(例: refs/heads/master;別のrefを指すrefは シンボリックref と呼ぶ)。便宜上、Gitコマンドの引数として使用する場合は refs/ を省略できる場合があります。詳細については gitrevisions(7) を参照してください。 refs は repository に保存されます。

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

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

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

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

<< def_ref,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) で深めることができます。

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

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

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

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

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

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

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

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

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

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

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

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

当該のブランチからマージされる(または当該のブランチがリベースされる)デフォルトのブランチ。これは、 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 ごとの構成ファイル)。