セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット作成
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの慣例
- 日々のGit
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
プラミングコマンド
-
2.49.0
2025-03-14
- 2.48.1 変更なし
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.2 変更なし
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.3 変更なし
-
2.44.0
2024-02-23
- 2.43.2 → 2.43.6 変更なし
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.39.1 → 2.42.4 変更なし
-
2.39.0
2022-12-12
- 2.25.1 → 2.38.5 変更なし
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 変更なし
-
2.24.0
2019-11-04
- 2.22.1 → 2.23.4 変更なし
-
2.22.0
2019-06-07
- 2.20.1 → 2.21.4 変更なし
-
2.20.0
2018-12-09
- 2.18.1 → 2.19.6 変更なし
- 2.18.0 変更なし
- 2.17.0 → 2.17.6 変更なし
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
- 2.13.7 → 2.14.6 変更なし
-
2.12.5
2017-09-22
- 2.11.4 変更なし
-
2.10.5
2017-09-22
- 2.7.6 → 2.9.5 変更なし
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
- 2.2.3 → 2.4.12 変更なし
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
説明
Gitリポジトリには2種類の形式があります
-
ワーキングツリーのルートにある
.git
ディレクトリ; -
ワーキングツリーを持たないbareリポジトリである
<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
-
このファイルは、このオブジェクトストアがオブジェクトを借用する代替オブジェクトストアへの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 fetch、git pull、git pushにURLを指定するために使用されるショートハンドを格納する非推奨の方法です。ファイルは
branches/<name>
として格納でき、その後nameをrepository引数の代わりとしてこれらのコマンドに与えることができます。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
-
リポジトリの現在のインデックスファイル。通常、ベアリポジトリには見つかりません。
-
$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 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とデフォルトの参照名のショートハンドを格納します。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
と同一ですが、以下の例外があります
-
core.repositoryformatversion
変数を読み取る際、バージョン1をサポートするGitの実装は、設定ファイルのextensions
セクションにある設定キーも読み取る必要があります。 -
バージョン1のリポジトリが、実行中のGitが実装していない
extensions.*
キーを指定している場合、操作は続行してはなりません。同様に、既知のキーの値が実装によって理解されない場合も、操作は続行してはなりません。
設定ファイルで拡張機能が指定されていない場合、core.repositoryformatversion
は0
に設定されるべきです(1
に設定してもメリットはなく、古いGitの実装との互換性がなくなります)。
定義された拡張機能は、git-config[1]のextensions.*
セクションに記載されています。新しい拡張機能を定義したい実装は、その名前を主張するために、そこにメモを残すべきです。
GIT
git[1]スイートの一部