セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
- 2.45.1 → 2.47.0 変更なし
-
2.45.0
04/29/24
- 2.44.1 → 2.44.2 変更なし
-
2.44.0
02/23/24
- 2.43.2 → 2.43.5 変更なし
-
2.43.1
02/09/24
-
2.43.0
11/20/23
- 2.39.1 → 2.42.3 変更なし
-
2.39.0
12/12/22
- 2.25.1 → 2.38.5 変更なし
-
2.25.0
01/13/20
- 2.24.1 → 2.24.4 変更なし
-
2.24.0
11/04/19
- 2.22.1 → 2.23.4 変更なし
-
2.22.0
06/07/19
- 2.20.1 → 2.21.4 変更なし
-
2.20.0
12/09/18
- 2.18.1 → 2.19.6 変更なし
- 2.18.0 変更なし
- 2.17.0 → 2.17.6 変更なし
-
2.16.6
12/06/19
-
2.15.4
12/06/19
- 2.13.7 → 2.14.6 変更なし
-
2.12.5
09/22/17
- 2.11.4 変更なし
-
2.10.5
09/22/17
- 2.7.6 → 2.9.5 変更なし
-
2.6.7
05/05/17
-
2.5.6
05/05/17
- 2.2.3 → 2.4.12 変更なし
-
2.1.4
12/17/14
-
2.0.5
12/17/14
説明
Git リポジトリには、2 つの異なる種類があります。
-
作業ツリーのルートにある
.git
ディレクトリ。 -
<project>.git
ディレクトリは、ベア リポジトリ(つまり、独自の作業ツリーを持たないリポジトリ)であり、通常は、プッシュとフェッチによって他のユーザーと履歴を交換するために使用されます。
注記: 作業ツリーのルートに、gitdir: <path>
を含むプレーンテキストファイル .git
を配置して、リポジトリが存在する実際のディレクトリを指定することもできます。このメカニズムはgitfileと呼ばれ、通常はgit submodule
と git worktree
コマンドで管理されます。これは、サブモジュールのチェックアウトの作業ツリーによく使用され、含まれている上位プロジェクトで、サブモジュールを持たないブランチをgit checkout
できるようにします。checkout
は、サブモジュールリポジトリを失うことなく、サブモジュールの作業ツリー全体を削除する必要があります。
これらの要素が Git リポジトリに存在する可能性があります。
- objects
-
このリポジトリに関連付けられたオブジェクトストア。通常、オブジェクトストアは自己完結型です(つまり、そこに含まれるオブジェクトによって参照されるすべてのオブジェクトもそこに含まれています)。ただし、これを破る方法はいくつかあります。
-
シャロークローンを作成することで、不完全ですがローカルで使用できるリポジトリを作成できます。git-clone[1] を参照してください。
-
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
-
このファイルには、HTTP を介してリポジトリがフェッチされる場合に使用される、このオブジェクトストアがオブジェクトを借用する代替オブジェクトストアのURLが記録されています。
- refs
-
参照は、このディレクトリのサブディレクトリに保存されます。git prune コマンドは、このディレクトリとそのサブディレクトリにある refs から到達可能なオブジェクトを保持することを認識しています。$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] によって内部的に使用および維持されます。そのような refs は、graft とは異なり、リポジトリ間で交換できます。 - packed-refs
-
refs/heads/、refs/tags/、および同様のファイルがより効率的な方法で記録する情報と同じ情報を記録します。git-pack-refs[1] を参照してください。$GIT_COMMON_DIR が設定されている場合、このファイルは無視され、代わりに "$GIT_COMMON_DIR/packed-refs" が使用されます。
- HEAD
-
現在アクティブなブランチを記述する
refs/heads/
名前空間へのシンボリック参照(用語集を参照)。リポジトリが作業ツリーに関連付けられていない場合(つまり、ベア リポジトリの場合)、あまり意味はありませんが、有効な Git リポジトリには必ず HEAD ファイルが必要です。一部のポーセレンは、リポジトリの指定された「デフォルト」ブランチ(通常はmaster)を推測するためにこれを使用する可能性があります。指定されたブランチnameがまだ存在しない場合でも、合法です。一部のレガシー設定では、シンボリック参照ではなく、現在のブランチを指すシンボリックリンクです。HEAD は、現在のブランチを指すシンボリック参照ではなく、特定のコミットを直接記録することもできます。このような状態は、多くの場合、デタッチ HEADと呼ばれます。git-checkout[1] で詳細を確認してください。
- config
-
リポジトリ固有の設定ファイル。$GIT_COMMON_DIR が設定されている場合、このファイルは無視され、代わりに "$GIT_COMMON_DIR/config" が使用されます。
- config.worktree
-
複数の作業ディレクトリ設定におけるメイン作業ディレクトリ用の作業ディレクトリ固有の設定ファイル(git-worktree[1] を参照)。
- branches
-
git fetch、git pull、git push を指定するために使用される省略形を保存する、やや非推奨の方法。ファイルは
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
-
リポジトリの現在のインデックスファイルです。通常、ベア型リポジトリには存在しません。
-
共有インデックス部分で、$GIT_DIR/indexやその他のテンポラリインデックスファイルによって参照されます。分割インデックスモードでのみ有効です。
- info
-
リポジトリに関する追加情報がこのディレクトリに記録されます。$GIT_COMMON_DIRが設定されていて、"$GIT_COMMON_DIR/info"が使用される場合は、このディレクトリは無視されます。
- info/refs
-
このファイルは、ダンプトランスポートがリポジトリで使用可能な参照を検出するのに役立ちます。リポジトリがダンプトランスポート用に公開されている場合、タグまたはブランチが作成または変更されるたびに、git update-server-infoによってこのファイルを再生成する必要があります。これは通常、
hooks/update
フックから実行されます。このフックは、git pushでリポジトリにプッシュするときに、git-receive-packコマンドによって実行されます。 - info/grafts
-
このファイルは、コミットの親の集合が実際にコミットが作成された方法とは異なるように見せかける、偽のコミットの祖先情報を記録します。1行あたりのレコードは、40バイトの16進数のオブジェクト名をスペースで区切り、改行で終了することで、コミットとその偽の親を記述します。
移植機構は時代遅れであり、リポジトリ間でオブジェクトを転送する際に問題を引き起こす可能性があることに注意してください。同様の処理を行うためのより柔軟で堅牢なシステムについては、git-replace[1]を参照してください。
- info/exclude
-
このファイルは、Porcelainコマンド間で、除外パターンリストを格納するために使用されます。
.gitignore
は、ディレクトリごとの無視ファイルです。git status、git add、git rm、git cleanはこれを参照しますが、Gitのコアコマンドはこれを参照しません。 gitignore[5]も参照してください。 - info/attributes
-
ディレクトリごとの
.gitattributes
ファイルと同様に、パスに割り当てる属性を定義します。gitattributes[5]も参照してください。 - info/sparse-checkout
-
このファイルは、スパースチェックアウトパターンを格納します。git-read-tree[1]も参照してください。
- remotes
-
git fetch、git pull、git pushコマンドを使用してリモートリポジトリとやり取りするときに使用するURLとデフォルトのrefnameの省略形を格納します。詳細は、git-fetch[1]のREMOTESセクションを参照してください。このメカニズムはレガシーであり、最新のレポジトリでは見つからない可能性があります。$GIT_COMMON_DIRが設定されていて、"$GIT_COMMON_DIR/remotes"が使用される場合は、このディレクトリは無視されます。
- 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
と同じです。
-
core.repositoryformatversion
変数を読み取るとき、バージョン1をサポートするGitの実装は、設定ファイルのextensions
セクションにある設定キーも読み取る必要があります。 -
バージョン1のリポジトリが、実行中のGitが実装していない
extensions.*
キーを指定した場合、操作は続行してはなりません。同様に、既知のキーの値が実装によって理解されていない場合、操作は続行してはなりません。
設定ファイルに拡張子が指定されていない場合、core.repositoryformatversion
は0
に設定する必要があります(1
に設定してもメリットはなく、古いGitの実装と互換性がなくなります)。
このドキュメントは、拡張子のマスターリストとして機能します。新しい拡張子を定義したい実装は、名前を主張するためにここにメモする必要があります。
定義されている拡張子は次のとおりです。
preciousObjects
設定キーextensions.preciousObjects
がtrue
に設定されている場合、リポジトリ内のオブジェクトは削除してはなりません(例:git-prune
またはgit repack -d
によって)。
partialClone
設定キーextensions.partialClone
が設定されている場合、それはレポが部分クローンで作成された(または後で部分フェッチを実行した)ことを示し、リモートは特定の不要なオブジェクトの送信を省略している可能性があります。そのようなリモートは「プロミサーリモート」と呼ばれ、そのような省略されたオブジェクトはすべて将来からフェッチできると約束します。
このキーの値は、プロミサーリモートの名前です。
Git
git[1]スイートの一部