日本語 ▾ トピック ▾ 最新バージョン ▾ gitrepository-layout は 2.49.0 で最終更新されました

名称

gitrepository-layout - Gitリポジトリのレイアウト

書式

$GIT_DIR/*

説明

Gitリポジトリには2種類の形式があります

  • ワーキングツリーのルートにある.gitディレクトリ;

  • ワーキングツリーを持たないbareリポジトリである<project>.gitディレクトリ。これは通常、プッシュやフェッチによって他者と履歴を交換するために使用されます。

: また、ワーキングツリーのルートに、リポジトリがある実際のディレクトリを指すgitdir: <path>を含むプレーンテキストファイル.gitを置くこともできます。このメカニズムはgitfileと呼ばれ、通常はgit submoduleおよびgit worktreeコマンドによって管理されます。これは、サブモジュールがまだないブランチを、含むスーパープロジェクトでgit checkoutできるように、サブモジュールのチェックアウトのワーキングツリーによく使用されます。checkoutはサブモジュールリポジトリを失うことなく、サブモジュールワーキングツリー全体を削除する必要があります。

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

objects

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

  1. シャロークローンを作成することで、不完全ながらローカルで利用可能なリポジトリを持つことができます。git-clone[1]を参照してください。

  2. objects/info/alternatesまたは$GIT_ALTERNATE_OBJECT_DIRECTORIESメカニズムを使用して、他のオブジェクトストアからオブジェクトを借りることができます。このような不完全なオブジェクトストアを持つリポジトリは、ダムトランスポートで使用するために公開するには適していませんが、objects/info/alternatesが借用元のオブジェクトストアを指している限り、問題ありません。

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

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

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

objects/pack

パック(多くのオブジェクトを圧縮形式で格納し、ランダムアクセスを可能にするインデックスファイルも含むファイル)はこのディレクトリにあります。

objects/info

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

objects/info/packs

このファイルは、ダムトランスポートがこのオブジェクトストアで利用可能なパックを発見するのに役立ちます。パックが追加または削除されるたびに、リポジトリがダムトランスポート用に公開されている場合は、このファイルを最新の状態に保つためにgit update-server-infoを実行する必要があります。git repackはデフォルトでこれを行います。

objects/info/alternates

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

objects/info/http-alternates

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

refs

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

refs/heads/name

ブランチnameのツリーの先端のコミットオブジェクトを記録します

refs/tags/name

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

refs/remotes/name

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

refs/replace/<obj-sha1>

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

packed-refs

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

HEAD

現在アクティブなブランチを記述するrefs/heads/名前空間へのシンボリック参照(用語集を参照)。リポジトリがどのワーキングツリーにも関連付けられていない場合(つまり、bareリポジトリの場合)、それほど意味はありませんが、有効なGitリポジトリにはHEADファイルが必須です。一部のポーセリンは、リポジトリの指定された「デフォルト」ブランチ(通常はmaster)を推測するためにこれを使用する場合があります。指定されたブランチnameが(まだ)存在しない場合でも合法です。一部のレガシーな設定では、現在のブランチを指すシンボリック参照ではなく、シンボリックリンクです。

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>として格納でき、その後namerepository引数の代わりとしてこれらのコマンドに与えることができます。git-fetch[1]のREMOTESセクションを参照してください。このメカニズムはレガシーであり、現代のリポジトリでは見られないでしょう。$GIT_COMMON_DIRが設定されている場合、このディレクトリは無視され、代わりに"$GIT_COMMON_DIR/branches"が使用されます。

Git 3.0では、Gitはこのディレクトリからのリモートの読み取りを停止します。

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および他のテンポラリインデックスファイルによって参照される共有インデックス部分。分割インデックスモードでのみ有効です。

info

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

info/refs

このファイルは、ダムトランスポートがこのリポジトリで利用可能な参照を発見するのに役立ちます。リポジトリがダムトランスポート用に公開されている場合、このファイルはタグまたはブランチが作成または変更されるたびに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 statusgit addgit rmgit cleanはこれを見ますが、コアGitコマンドはこれを見ません。参照:gitignore[5]

info/attributes

パスに割り当てる属性を定義します。ディレクトリごとの.gitattributesファイルに似ています。参照:gitattributes[5]

info/sparse-checkout

このファイルはスパースチェックアウトパターンを格納します。参照:git-read-tree[1]

remotes

git fetchgit pullgit pushコマンドを介してリモートリポジトリと対話する際に使用するURLとデフォルトの参照名のショートハンドを格納します。git-fetch[1]のREMOTESセクションを参照してください。このメカニズムはレガシーであり、現代のリポジトリでは見られないでしょう。$GIT_COMMON_DIRが設定されている場合、このディレクトリは無視され、代わりに"$GIT_COMMON_DIR/remotes"が使用されます。

Git 3.0では、Gitはこのディレクトリからのリモートの読み取りを停止します。

logs

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

logs/refs/heads/name

ブランチの先端nameに行われたすべての変更を記録します。

logs/refs/tags/name

タグnameに行われたすべての変更を記録します。

shallow

これはinfo/graftsに似ていますが、シャロークローンメカニズムによって内部的に使用および維持されます。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

リンクされたワーキングツリーの管理データを格納します。各サブディレクトリには、リンクされたワーキングツリーのワーキングツリー関連部分が含まれます。$GIT_COMMON_DIRが設定されている場合、このディレクトリは無視され、その場合は"$GIT_COMMON_DIR/worktrees"が代わりに使用されます。

worktrees/<id>/gitdir

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

worktrees/<id>/locked

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

worktrees/<id>/config.worktree

ワーキングディレクトリ固有の設定ファイル。

Gitリポジトリ形式のバージョン

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

このルールのために、バージョンアップは最小限に抑えるべきです。代わりに、一般的に以下の戦略を推奨します

  • 個々のデータファイル(例:インデックス、パックファイルなど)の形式バージョン番号を上げる。これにより、非互換性はそのファイルにのみ限定されます。

  • 古いクライアントで使用された場合でも適切に機能する新しいデータを導入する(例:パックビットマップファイルは古いクライアントには無視され、それらが提供する最適化を利用しないだけです)。

リポジトリ全体の形式バージョンの更新は、独立してバージョン管理できない変更の一部であるべきです。例えば、オブジェクトへの到達可能性ルールや参照のロックルールを変更する場合、リポジトリ形式バージョンの更新が必要になります。

これは、リポジトリのディスク内容に直接アクセスする場合にのみ適用されることに注意してください。形式0のみを理解する古いクライアントでも、サーバープロセスが形式1を理解している限り、形式1を使用するリポジトリにgit://経由で接続できます。

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

現在定義されている形式バージョンは次のとおりです

バージョン0

これはGitの初期バージョンで定義された形式で、リポジトリディレクトリの形式、リポジトリ設定ファイル、オブジェクトおよび参照の保存形式などが含まれますが、これらに限定されません。Gitの完全な動作を規定することは、このドキュメントの範囲外です。

バージョン1

この形式はバージョン0と同一ですが、以下の例外があります

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

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

設定ファイルで拡張機能が指定されていない場合、core.repositoryformatversion0に設定されるべきです(1に設定してもメリットはなく、古いGitの実装との互換性がなくなります)。

定義された拡張機能は、git-config[1]extensions.*セクションに記載されています。新しい拡張機能を定義したい実装は、その名前を主張するために、そこにメモを残すべきです。

GIT

git[1]スイートの一部

scroll-to-top