セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
- 2.49.1 → 2.50.1 変更なし
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 変更なし
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.3 変更なし
-
2.45.0
2024-04-29
- 2.44.1 → 2.44.4 変更なし
-
2.44.0
2024-02-23
- 2.43.2 → 2.43.7 変更なし
-
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
ディレクトリ。 -
「ベアリポジトリ」(つまり、独自の作業ツリーを持たない)である <project>
.git
ディレクトリで、通常は他の人と履歴をプッシュしたりフェッチしたりして交換するために使用されます。
注意:作業ツリーのルートにプレーンテキストファイル .git
を置き、リポジトリを持つ実際のディレクトリを指す gitdir:
<path> を含めることもできます。このメカニズムは「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」コマンドは、このディレクトリとそのサブディレクトリで見つかるrefから到達可能なオブジェクトを保持することを知っています。このディレクトリは、$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] によって内部的に使用および維持されます。このようなrefはリポジトリ間で交換できますが、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」にURLを指定するために使用されるショートハンドを保存する非推奨の方法です。ファイルは
branches/
<name> として保存でき、その後、これらのコマンドに「repository」引数の代わりに「name」を与えることができます。詳細については、git-fetch[1] のREMOTESセクションを参照してください。このメカニズムはレガシーであり、現代のリポジトリでは見られない可能性が高いです。このディレクトリは、$GIT_COMMON_DIR が設定されている場合は無視され、代わりに "$GIT_COMMON_DIR/branches" が使用されます。Git 3.0 では、このディレクトリからリモートを読み取るのを停止します。
- 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進数オブジェクト名をスペースで区切り、改行で終端して記述します。
グラフトメカニズムは古く、リポジトリ間のオブジェクト転送で問題を引き起こす可能性があることに注意してください。同じことをより柔軟で堅牢なシステムで行うには、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のショートハンドとデフォルトのrefnameを保存します。詳細については、git-fetch[1] のREMOTESセクションを参照してください。このメカニズムはレガシーであり、現代のリポジトリでは見られない可能性が高いです。このディレクトリは、$GIT_COMMON_DIR が設定されている場合は無視され、代わりに "$GIT_COMMON_DIR/remotes" が使用されます。
Git 3.0 では、このディレクトリからリモートを読み取るのを停止します。
- 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 ファイルへの絶対パスを含むテキストファイル。これは、リンクされたリポジトリが手動で削除されたかどうか、このディレクトリを保持する必要があるかどうかを確認するために使用されます。このファイルの最終更新時刻は、リンクされたリポジトリにアクセスするたびに更新されるべきです。
- worktrees/<id>/locked
-
このファイルが存在する場合、リンクされた作業ツリーはポータブルデバイス上にあり、利用できない可能性があります。このファイルの存在により、
worktrees/
<id> が自動または手動でgit
worktree
prune
によって削除されるのを防ぎます。このファイルには、リポジトリがロックされている理由を説明する文字列が含まれている場合があります。 - worktrees/<id>/config.worktree
-
作業ディレクトリ固有の設定ファイル。
Gitリポジトリのフォーマットバージョン
すべてのgitリポジトリは、config
ファイルの core.repositoryformatversion
キーに数値バージョンでマークされています。このバージョンは、ディスク上のリポジトリデータに対する操作ルールを指定します。ディスク上のリポジトリがアドバタイズする特定のバージョンを理解しないgitの実装は、そのリポジトリで動作してはなりません。そうすると、誤った結果を生むだけでなく、実際にデータを失うリスクがあります。
このルールのため、バージョンアップは絶対最小限に抑えるべきです。代わりに、一般的に以下の戦略を好みます。
-
個々のデータファイル(例:インデックス、パックファイルなど)のフォーマットバージョン番号を上げる。これにより、非互換性はそれらのファイルのみに限定されます。
-
古いクライアントで使用されても gracefully に機能する新しいデータを導入する(例:パックビットマップファイルは古いクライアントには無視され、提供される最適化の恩恵を受けないだけです)。
リポジトリ全体のフォーマットバージョンアップは、独立してバージョン管理できない変更の一部である場合にのみ行われるべきです。たとえば、オブジェクトの到達可能性ルールやrefのロックルールを変更する場合、リポジトリフォーマットバージョンの変更が必要です。
これは、リポジトリのディスク内容に直接アクセスする場合にのみ適用されることに注意してください。0
フォーマットしか理解しない古いクライアントでも、サーバープロセスが 1
フォーマットを理解する限り、git://
を介して 1
フォーマットを使用するリポジトリに接続できます。
バージョンアップ(リポジトリ全体または単一ファイルの場合)を展開する推奨される戦略は、新しいフォーマットを読み取るようにGitを教育し、設定スイッチまたはコマンドラインオプション(実験用または古いGitとの後方互換性を気にしない人向け)で新しいフォーマットの書き込みを許可することです。そして、読み取り機能が一般的になるまで長い期間を置いた後、デフォルトで新しいフォーマットを書き込むように切り替えることができます。
現在定義されているフォーマットバージョンは次のとおりです。
バージョン 0
これは、Gitの初期バージョンによって定義されたフォーマットであり、リポジトリディレクトリ、リポジトリ設定ファイル、およびオブジェクトとrefストレージのフォーマットを含みますが、これらに限定されません。Gitの完全な動作を指定することは、このドキュメントの範囲を超えています。
バージョン 1
このフォーマットはバージョン 0
と同一ですが、以下の例外があります。
-
core.repositoryformatversion
変数を読み取る際、バージョン 1 をサポートする git 実装は、設定ファイルのextensions
セクションにある設定キーも読み取る必要があります。 -
バージョン1のリポジトリが、実行中のgitが実装していない
extensions.*
キーを指定した場合、操作は続行されてはなりません。同様に、既知のキーの値が実装によって理解されない場合、操作は続行されてはなりません。
設定ファイルに拡張機能が指定されていない場合、core.repositoryformatversion
は 0
に設定するべきであることに注意してください(1
に設定しても利点はなく、古いGitの実装との互換性がなくなります)。
定義されている拡張機能は、git-config[1] の extensions.*
セクションに記載されています。新しい拡張機能を定義したい実装は、その名前を主張するためにそこにメモを残すべきです。
GIT
git[1]スイートの一部