SYNOPSIS

$GIT_DIR/*

DESCRIPTION

Gitリポジトリには2つの風味があります:

  • 作業ツリーのルートにある .git ディレクトリ

  • bare(裸の)リポジトリである(つまり、独自の作業ツリーがない)「<project>.git」ディレクトリ。通常、このディレクトリにプッシュしてフェッチすることにより、他のユーザーと履歴を交換するために使用されます。

注意: また、 作業ツリーのルートにプレーン・テキスト・ファイル .git を置くことができ、 その中に gitdir: <path> を記述して、 リポジトリーが存在する実際のディレクトリーを指すことができます。 この仕組みは gitfile と呼ばれ、 通常は git submodulegit worktree コマンドを通じて管理されます。 これは、 submodule checkout による作業ツリーでよく使用され、 包含するスーパー・プロジェクト内で、 サブモジュールを持たないブランチを git checkout できるようにします。 checkout では、 サブモジュールの作業ツリー全体を削除する必要がありますが、 サブモジュールのリポジトリー自体は失われません。

以下のものがGitリポジトリに存在する可能性があります。

objects

このリポジトリーに関連付けられているオブジェクト・ストア。 通常、 オブジェクト・ストアは自己完結です(つまり、 そこにあるオブジェクトによって参照されるすべてのオブジェクトもそこにあります)が、 それを破る方法がいくつかあります。

  1. 浅いクローン(shallow clone)を作成することにより、不完全であるがローカルで使用可能なリポジトリを作成できます。 git-clone(1) を参照してください。

  2. objects/info/alternates または $GIT_ALTERNATE_OBJECT_DIRECTORIES メカニズムを使用して、他のオブジェクトストアからオブジェクトを「借用」(borrow)することができます。この種の不完全なオブジェクトストアを持つリポジトリは、馬鹿プロトコル(dumb transport)で使用するために公開するのには適していませんが、それ以外の場合は「objects/info/alternates」が借用するオブジェクトストアを指している限り問題ありません。

    $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/objects」が使用されます。

objects/[0-9a-f][0-9a-f]

新しく作成されたオブジェクトは、独自のファイルに保存されます。オブジェクトは、sha1オブジェクト名の最初の2文字を使用して、256個のサブディレクトリに分散され、 objects 自体のディレクトリエントリの数を管理可能な数に保ちます。ここにあるオブジェクトは、「アンパックオブジェクト」(unpacked obuject)(または「ルーズオブジェクト」(loose object))と呼ばれることがよくあります。

objects/pack

パック(多くのオブジェクトを圧縮形式で格納するファイルと、ランダムにアクセスできるようにするためのインデックスファイル)は、このディレクトリにあります。

objects/info

オブジェクトストアに関する追加情報は、このディレクトリに記録されます。

objects/info/packs

このファイルは、馬鹿プロトコルがこのオブジェクトストアで使用可能なパックを検出するのに役立ちます。リポジトリが馬鹿プロトコル用に公開されている場合は、パックを追加または削除するたびに、 git update-server-info を実行して、このファイルを最新の状態に保つ必要があります。 git repack はデフォルトでこれを行います。

objects/info/alternates

このファイルは、このオブジェクトストアがオブジェクトを借用(borrow)する代替オブジェクトストアへのパスを、1行に1つのパス名で記録します。ネイティブGitツールがローカルで使用するだけでなく、HTTP fetcher もリモートで使用しようとすることに注意してください。これは通常、代替ファイルに相対パス(リポジトリではなくオブジェクトデータベースに対して!)がある場合は機能しますが、ファイルシステムとWeb URLの絶対パスが同じでない限り、絶対パスを使用する場合は機能しません。 objects/info/http-alternates も参照してください。

objects/info/http-alternates

このファイルは、このオブジェクトストアがオブジェクトを借用(borrow)する代替オブジェクトストアへのURLを記録し、リポジトリがHTTP経由でフェッチされるときに使用されます。

refs

参照(reference)は、 このディレクトリーのサブディレクトリーに保存されます。 git prune コマンドは、 このディレクトリーとそのサブディレクトリーで見つかった参照から到達可能なオブジェクトを認識し保持します。 $GIT_COMMON_DIR が設定されていて、代わりに $GIT_COMMON_DIR/refs が使用される場合、 このディレクトリーは無視されます( refs/bisectrefs/rewrittenrefs/worktree を除く)。

refs/heads/name

ブランチ name のツリーの先端(tip-of-the-tree)のコミットオブジェクトを記録します

refs/tags/name

オブジェクト名を記録します(必ずしもコミットオブジェクト、またはコミットオブジェクトを指すタグオブジェクトである必要はありません)。

refs/remotes/name

リモートリポジトリからコピーされたブランチのツリーの先端(tip-of-the-tree)のコミットオブジェクトを記録します。

refs/replace/<obj-sha1>

<obj-sha1> を置き換えるオブジェクトのSHA-1を記録します。これはinfo/graftsに似ており、 git-replace(1) によって内部的に使用および保守されます。 このような参照はリポジトリ間で交換できますが、 grafts はできません。

packed-refs

refs/heads/ や refs/tags/ と同じ情報を記録し、そして friends がより効率的な方法で記録します。 git-pack-refs(1) を参照してください。 $GIT_COMMON_DIR が設定されている場合、このファイルは無視され、代わりに「$GIT_COMMON_DIR/packed-refs」が使用されます。

HEAD

現在アクティブなブランチを説明する refs/heads/ 名前空間へのシンボリック参照(symref;glossaryを参照)。 リポジトリーが作業ツリーに関連付けられていない場合(つまり、ベア・リポジトリーの場合)はあまり意味がありませんが、 有効な Git リポジトリーには HEAD ファイルが「必要」です。 一部の磁器コマンドは、 これを使用して、 リポジトリーの指定された「デフォルト」ブランチ(通常は「master」)を推測する場合があります。 名前付きブランチ name が(まだ)存在しない場合も合法です。 一部のレガシー設定では、 現在のブランチを指すシンボリック参照(symref)ではなくシンボリック・リンクです。

HEADは、 現在のブランチを指すシンボリック参照(symref)である代わりに、 特定のコミットを直接記録することもできます。 このような状態はしばしば「切り離されたHEAD」(detached HEAD)と呼ばれます。 詳細については git-checkout(1)を参照してください。

config

リポジトリ固有の構成ファイル。 $GIT_COMMON_DIR が設定されている場合、このファイルは無視され、代わりに「$GIT_COMMON_DIR/config」が使用されます。

config.worktree

複数の作業ディレクトリ設定の、メイン作業ディレクトリための、作業ディレクトリ固有の構成ファイル(git-worktree(1) を参照)。

branches

git fetchgit pullgit push へのURLを指定するために使用される短縮形を格納するための、少々非推奨の方法。ファイルは branches/<name> として保存でき、 repository 引数の代わりに name をこれらのコマンドに指定できます。詳細については、 git-fetch(1) の REMOTES セクションを参照してください。この機構はレガシーであり、最新のリポジトリには見られない可能性があります。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/branches」が使用されます。

hooks

フックは、さまざまなGitコマンドで使用されるカスタマイズスクリプトです。 git init を実行すると、いくつかのサンプルフックがインストールされますが、デフォルトではすべて無効になっています。有効にするには、ファイル名から .sample サフィックスを削除して名前を変更する必要があります。各フックの詳細については、 githooks(5) をお読みください。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/hooks」が使用されます。

common

複数の作業ツリーが使用されている場合、 $GIT_DIR 内のほとんどのファイルは、 いくつかの既知の例外を除いて、 各作業ツリー毎にあります。 ただし、「common」の下にあるすべてのファイルは、 すべての作業ツリー間で共有されます。

index

リポジトリの現在のインデックスファイル。通常、ベアリポジトリには見つかりません。

sharedindex.<SHA-1>

$GIT_DIR/indexおよびその他の一時(temporary)インデックスファイルによって参照される共有インデックス部分。スプリットインデックスモード(split index mode)でのみ有効です。

info

リポジトリに関する追加情報は、このディレクトリに記録されます。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/info」が使用されます。

info/refs

このファイルは、 馬鹿プロトコル(dumb transports)がこのリポジトリーで使用可能な参照を検出するのに役立ちます。 リポジトリーが馬鹿プロトコル用に公開されている場合、 このファイルは、 タグまたはブランチが作成または変更されるたびに、 git update-server-info によって再生成される必要があります。 これは通常、 リポジトリーに git push したときに git-receive-pack コマンドによって実行される hooks/update フックから実行されます。

info/grafts

このファイルは、コミットが実際に作成された方法とは異なる親のセットを装うために、偽のコミットの祖先情報を記録します。1行に1つのレコードは、スペースで区切られ、改行で終了する40バイトの16進オブジェクト名をリストすることにより、コミットとその偽の親を記述します。

graftsメカニズムは古臭く、リポジトリ間でオブジェクトを転送する際に問題が発生する可能性があることに注意してください。 同じことを行うためのより柔軟で堅牢なシステムについては、 git-replace(1) を参照してください。

info/exclude

このファイルは、磁器コマンドの慣例により、除外パターンリストを格納します。 .gitignore は、ディレクトリごとの無視ファイルです。「git status」、「git add」、「git rm」、「git clean」はこの除外パターンリストを調べますが、コアGitコマンドはこの除外パターンリストを調べません。 gitignore(5) も参照してください。

info/attributes

ディレクトリごとの .gitattributes ファイルと同様に、パスに割り当てる属性を定義します。 gitattributes(5) も参照してください。

info/sparse-checkout

このファイルには、スパースチェックアウトパターン(sparse checkout patterns)が格納されています。 git-read-tree(1) も参照してください。

remotes

git fetchgit pullgit push コマンドを介してリモート・リポジトリーと対話するときに使用するURLの省略形とデフォルトの参照名を格納します。 詳細については、 git-fetch(1)のREMOTESセクションを参照してください。 このメカニズムはレガシーであり、 最新のリポジトリーには見られない可能性があります。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、 代わりに $GIT_COMMON_DIR/remotes が使用されます。

logs

参照に加えられた変更の記録は、 このディレクトリに保存されます。 詳細については、 git-update-ref(1) を参照してください。 $GIT_COMMON_DIR が設定されていて、 代わりに $GIT_COMMON_DIR/logs が使用される場合、 このディレクトリは無視されます(但し、 logs/HEAD を除く)。

logs/refs/heads/name

name という名前のブランチ先端(branch tip)に加えられたすべての変更を記録します。

logs/refs/tags/name

name という名前のタグに加えられたすべての変更を記録します。

shallow

これは info/grafts に似ていますが、内部的に使用され、浅いクローンメカニズム(shallow clone mechanism)によって維持されます。 git-clone(1)git-fetch(1)--depth オプションを参照してください。 $GIT_COMMON_DIRが設定されている場合、このファイルは無視され、代わりに「$GIT_COMMON_DIR/shallow」が使用されます。

commondir

このファイルが存在する場合、明示的に設定されていなければ、 $GIT_COMMON_DIR (git(1) を参照)はこのファイルで指定されたパスに設定されます。指定されたパスが相対パスの場合、それは$GIT_DIRからの相対パスです。commondirのあるリポジトリは、「commondir」が指すリポジトリがないと不完全です。

modules

サブモジュールのgitリポジトリが含まれています。

worktrees

リンクされた作業ツリー(linked working trees)の管理データが含まれています。各サブディレクトリには、リンクされた作業ツリーの作業ツリー関連部分が含まれています。 $GIT_COMMON_DIRが設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/worktrees」が使用されます。

worktrees/<id>/gitdir

ここを指す .git ファイルへの絶対パスを含むテキストファイル。 これは、 リンクされたリポジトリが手動で削除されたかどうかを確認するために使用され、 このディレクトリを保持する必要がなくなった場合に役立ちます。 このファイルの最終変更時刻(mtime)は、 リンクされたリポジトリーにアクセスするたびに更新されるべきです。

worktrees/<id>/locked

このファイルが存在する場合、リンクされた作業ツリーがポータブルデバイス上にあり、使用できない可能性があります。このファイルが存在すると、 git worktree prune によって worktrees/<id> が自動または手動で剪定(prune)されるのを防ぎます。ファイルには、リポジトリがロックされている理由を説明する文字列が含まれている場合があります。

worktrees/<id>/config.worktree

作業ディレクトリ固有の構成ファイル。

Git Repository Format Versions

すべてのgitリポジトリは、その config ファイルの core.repositoryformatversion キーに、バージョン数値が印されています。このバージョン数値は、ディスク上のリポジトリデータを操作するためのルールを指定します。 ディスク上のリポジトリから告知された特定のバージョンを理解しないgitの実装は、そのリポジトリで動作してはなりません。そうすることは、間違った結果を生み出すだけでなく、実際にデータを失うリスクがあります。

このルールのため、バージョンアップは最小限に抑える必要があります。代わりに、我々は一般的に以下の戦略を好みます:

  • 個々のデータファイル(インデックス、パックファイルなど)のフォーマットバージョン番号をバージョンアップします。これにより、非互換性がそれらのファイルのみに制限されます。

  • 古いクライアントで使用すると正常に機能制限される(gracefully degrade)新しいデータを導入します(たとえば、パックビットマップファイルは古いクライアントでは無視され、提供される最適化を利用しません)。

リポジトリ全体の形式のバージョンアップは、個別にバージョン管理できない部分だけにするべきです。たとえば、オブジェクトの到達可能性ルール、またはrefをロックするためのルールを変更する場合、リポジトリ形式バージョンのバージョンアップが必要になります。

注意: これはリポジトリーのディスク内容に直接アクセスする場合にのみ適用されます。 フォーマット 0 のみを理解する古いクライアントは、 サーバー・プロセスがフォーマット 1 を理解していれば、 フォーマット 1 を使用するリポジトリーに git:// を介して接続することができます。

(リポジトリー全体または単一のファイルに対する)バージョンの更新を展開する際の推奨戦略は、 Git に新しいフォーマットを読み取る機能を教え、 設定スイッチまたはコマンドライン・オプションを使用して新しいフォーマットを書き込むことを許可することです(実験用、 または古い Git との後方互換性を気にしないユーザーのために)。 その後、 新しいフォーマットを読み込む機能が一般的になるまで十分な期間を設けた後で、 デフォルトで新しいフォーマットを書き込むように切り替えることができます。

現在定義されているフォーマット・バージョンは以下のとおりです:

Version 0

これは、 Git の初期バージョンで定義されたフォーマットで、 リポジトリー・ディレクトリや、 リポジトリー設定ファイルや、 オブジェクトと参照ストレージのフォーマットを含みますが、 これに限定されません。 しかし、 Git の振る舞いを余すところなく記述することは、 このドキュメントの役割ではありません(Specifying the complete behavior of git is beyond the scope of this document).

Version 1

この形式は、以下の例外を除いて、バージョン 0 と同じです:

  1. core.repositoryformatversion 変数を読み取る場合、バージョン1をサポートするgit実装は、構成ファイルの extensions セクションにある構成キーも読み取る必要があります。

  2. バージョン1リポジトリが、実行中のgitが実装していない extensions.* キーを指定している場合、操作の続行は禁止です。同様に、既知のキーの値が実装によって理解されない場合、操作の続行は禁止です。

注意: 設定ファイルに拡張機能(extension)の指定が無い場合は、 core.repositoryformatversion0 に設定する必要があります(`1`に設定してもメリットはなく、リポジトリはgitの古い実装と互換性がなくなります)。

定義済みの拡張機能(extensions)は、 git-config(1)extensions.* セクションに記載されています。 新しい拡張機能を定義したい実装は、 その名前を宣言するために、 そこにその旨を記載する必要があります。

SEE ALSO

GIT

Part of the git(1) suite