SYNOPSIS
$GIT_DIR/*
DESCRIPTION
Gitリポジトリには2つの風味があります:
-
作業ツリーのルートにある
.git
ディレクトリ -
bare(裸の)リポジトリである(つまり、独自の作業ツリーがない)「<project>.git」ディレクトリ。通常、このディレクトリにプッシュしてフェッチすることにより、他のユーザーと履歴を交換するために使用されます。
注意: また、 作業ツリーのルートにプレーン・テキスト・ファイル .git
を置くことができ、
その中に gitdir:
<path> を記述して、
リポジトリーが存在する実際のディレクトリーを指すことができます。
この仕組みは gitfile
と呼ばれ、
通常は git
submodule
や git
worktree
コマンドを通じて管理されます。
これは、 submodule checkout による作業ツリーでよく使用され、
包含するスーパー・プロジェクト内で、
サブモジュールを持たないブランチを git
checkout
できるようにします。 checkout
では、
サブモジュールの作業ツリー全体を削除する必要がありますが、 サブモジュールのリポジトリー自体は失われません。
以下のものがGitリポジトリに存在する可能性があります。
- objects
-
このリポジトリーに関連付けられているオブジェクト・ストア。 通常、 オブジェクト・ストアは自己完結です(つまり、 そこにあるオブジェクトによって参照されるすべてのオブジェクトもそこにあります)が、 それを破る方法がいくつかあります。
-
浅いクローン(shallow clone)を作成することにより、不完全であるがローカルで使用可能なリポジトリを作成できます。 git-clone(1) を参照してください。
-
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/bisect
とrefs/rewritten
とrefs/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
fetch
やgit
pull
やgit
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
fetch
やgit
pull
やgit
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
と同じです:
-
core.repositoryformatversion
変数を読み取る場合、バージョン1をサポートするgit実装は、構成ファイルのextensions
セクションにある構成キーも読み取る必要があります。 -
バージョン1リポジトリが、実行中のgitが実装していない
extensions.
* キーを指定している場合、操作の続行は禁止です。同様に、既知のキーの値が実装によって理解されない場合、操作の続行は禁止です。
注意: 設定ファイルに拡張機能(extension)の指定が無い場合は、 core.repositoryformatversion
を 0
に設定する必要があります(`1`に設定してもメリットはなく、リポジトリはgitの古い実装と互換性がなくなります)。
定義済みの拡張機能(extensions)は、 git-config(1) の extensions.
* セクションに記載されています。 新しい拡張機能を定義したい実装は、 その名前を宣言するために、 そこにその旨を記載する必要があります。
SEE ALSO
GIT
Part of the git(1) suite