SYNOPSIS

$GIT_DIR/*

DESCRIPTION

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

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

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

: また、作業ツリーのルートにプレーンテキストファイル .git を作成できます。 このファイルには、リポジトリがある実際のディレクトリを指す gitdir: <path> が含まれています。 このメカニズムは、サブモジュールチェックアウトの作業ツリーによく使用され、 サブモジュールを含むスーパープロジェクトで、 サブモジュールを持たないブランチを「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 コマンドは、このディレクトリとそのサブディレクトリに見つかったrefsから到達可能なオブジェクトを認識し保持します。$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) によって内部的に使用および保守されます。 このようなrefsはリポジトリ間で交換できますが、graftsは交換できません。

packed-refs

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

HEAD

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

HEADは、現在のブランチを指すシンボリックref(symref)である代わりに、特定のコミットを直接記録することもできます。このような状態は「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)がこのリポジトリで使用可能な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の省略形とデフォルトのref名を格納します。詳細については、 git-fetch(1)のREMOTESセクションを参照してください。このメカニズムはレガシーであり、最新のリポジトリには見られない可能性があります。 $GIT_COMMON_DIR が設定されている場合、このディレクトリは無視され、代わりに「$GIT_COMMON_DIR/remotes」が使用されます。

logs

refに加えられた変更の記録は、このディレクトリに保存されます。詳細については、 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の初期バージョンで定義されている形式であり、リポジトリディレクトリ、リポジトリ構成ファイル、オブジェクトおよびrefストレージの形式が含まれま すが、これらに限定されません。gitの完全な動作を記述することは、このドキュメントの役割ではありません。

Version 1

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

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

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

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

このドキュメントは、拡張機能のマスターリストとして機能します。新しい拡張機能を定義したい実装は、名前を主張するために、ここにそれを書き留めておく必要があります。

定義されている拡張機能は以下のとおりです:

noop

この拡張機能は、gitの動作をまったく変更しません。 これは、フォーマット1の互換性をテストする場合にのみ役立ちます。

preciousObjects

設定キー extensions.preciousObjectstrue に設定されている場合、リポジトリ内のオブジェクトを削除してはなりません(たとえば、 git-prune または git repack -d など)。

partialClone

設定キー extensions.partialClone が設定されている場合、リポジトリが部分クローンで作成された(または後で部分フェッチを実行した)こと、およびリモートが特定の不要なオブジェクトの送信を省略した可能性があることを示します。 このようなリモートはpromisor remoteと呼ばれ、将来、このような省略されたオブジェクトをすべてフェッチできることを約束します。

このキーの値は、promisor remoteの名前です。

worktreeConfig

設定されている場合、デフォルトでは、「git config」はGIT_DIRの「config」ファイルと「config.worktree」ファイルの両方からこの順序で読み取ります。複数の作業ディレクトリモードでは、「config.worktree」が作業ディレクトリごとにある間(つまり、 GIT_COMMON_DIR/worktrees/<id>/config.worktree にあります)、「config」ファイルは共有されます。

SEE ALSO

GIT

Part of the git(1) suite