セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの規約
- 日々のGit
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
低レベルコマンド
- 2.43.1 → 2.47.0 変更なし
-
2.43.0
11/20/23
- 2.40.1 → 2.42.3 変更なし
-
2.40.0
03/12/23
- 2.39.1 → 2.39.5 変更なし
-
2.39.0
12/12/22
- 2.37.1 → 2.38.5 変更なし
-
2.37.0
06/27/22
- 2.36.1 → 2.36.6 変更なし
-
2.36.0
04/18/22
- 2.34.1 → 2.35.8 変更なし
-
2.34.0
11/15/21
- 2.27.1 → 2.33.8 変更なし
-
2.27.0
06/01/20
- 2.25.1 → 2.26.3 変更なし
-
2.25.0
01/13/20
- 2.22.1 → 2.24.4 変更なし
-
2.22.0
06/07/19
- 2.18.1 → 2.21.4 変更なし
-
2.18.0
06/21/18
- 2.17.0 → 2.17.6 変更なし
-
2.16.6
12/06/19
- 2.15.4 変更なし
-
2.14.6
12/06/19
-
2.13.7
05/22/18
- 2.2.3 → 2.12.5 変更なし
-
2.1.4
12/17/14
-
2.0.5
12/17/14
概要
git read-tree [(-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>) [-u | -i]] [--index-output=<file>] [--no-sparse-checkout] (--empty | <tree-ish1> [<tree-ish2> [<tree-ish3>]])
説明
<tree-ish> で指定されたツリー情報をインデックスに読み込みますが、実際に「キャッシュ」するファイルは**更新**しません。(参照: git-checkout-index[1])
オプションで、-m フラグを使用して、ツリーをインデックスにマージしたり、早送り（つまり2ウェイ）マージ、または3ウェイマージを実行したりできます。 -m と一緒に使用すると、-u フラグは、マージ結果で作業ツリー内のファイルも更新します.
git read-tree 自体では、簡単なマージのみが行われます。 git read-tree が戻るとき、競合するパスのみが未マージ状態になります。
オプション
- -m
-
読み込みだけでなく、マージを実行します. インデックスファイルに未マージのエントリがある場合、コマンドは実行を拒否します.これは、開始した以前のマージが完了していないことを示しています.
- --reset
-
-m と同じですが、失敗する代わりに未マージのエントリが破棄されます。
-uと共に使用すると、作業ツリーの変更または追跡されていないファイルまたはディレクトリの損失につながる更新は、操作を中止しません. - -u
-
マージが成功した後、作業ツリー内のファイルをマージ結果で更新します.
- -i
-
通常、マージでは、ローカルの変更を失わないように、インデックスファイルと作業ツリー内のファイルが現在のヘッドコミットと最新の状態である必要があります。 このフラグは、作業ツリーによるチェックを無効にし、現在の作業ツリーの状態に直接関係のないツリーのマージを一時インデックスファイルに作成するときに使用することを目的としています.
- -n
- --dry-run
-
インデックスまたは作業ツリー内のファイルを実際に更新することなく、コマンドがエラーになるかどうかを確認します.
- -v
-
ファイルをチェックアウトする際の進行状況を表示します.
- --trivial
-
git read-tree による3ウェイマージを、ファイルレベルのマージが必要ない場合にのみ発生するように制限します.些細なケースのマージを解決し、競合するファイルをインデックスで未解決のままにするのではなく.
- --aggressive
-
通常、git read-tree による3ウェイマージは、本当に些細なケースのマージを解決し、他のケースはインデックスで未解決のままにします。そのため、porcelainは異なるマージポリシーを実装できます。 このフラグにより、コマンドは内部でさらにいくつかのケースを解決します.
-
片側がパスを削除し、反対側がパスを変更しないままにした場合。 解決策は、そのパスを削除することです.
-
両側がパスを削除する場合。 解決策は、そのパスを削除することです.
-
両側が同じパスを追加する場合。 解決策は、そのパスを追加することです.
-
- --prefix=<prefix>
-
現在のインデックスの内容を保持し、指定されたtree-ishの内容を
<prefix>のディレクトリの下に読み込みます。 コマンドは、元のインデックスファイルに既に存在するエントリを上書きすることを拒否します. - --index-output=<file>
-
結果を
$GIT_INDEX_FILEに書き込む代わりに、結果のインデックスを指定されたファイルに書き込みます。 コマンドの実行中は、元のインデックスファイルは通常と同じメカニズムでロックされます。 ファイルは、通常のインデックスファイルの隣に作成される一時ファイルからrename(2)されることを許可する必要があります。 通常、これはインデックスファイル自体と同じファイルシステム上にある必要があることを意味し、インデックスファイルとインデックス出力ファイルが配置されているディレクトリへの書き込み権限が必要です. - --[no-]recurse-submodules
-
--recurse-submodules を使用すると、read-tree を再帰的に呼び出すことにより、スーパープロジェクトに記録されたコミットに従ってすべてのアクティブなサブモジュールの内容が更新されます。また、サブモジュールの HEAD がそのコミットでデタッチされるように設定されます.
- --no-sparse-checkout
-
core.sparseCheckoutがtrueの場合でも、スパースチェックアウトサポートを無効にします. - --empty
-
ツリーオブジェクトをインデックスに読み込む代わりに、単に空にします.
- -q
- --quiet
-
静かに、フィードバックメッセージを抑制します.
- <tree-ish#>
-
読み込み/マージされるツリーオブジェクトのID.
マージ
-m が指定されている場合、_git read-tree_ は3種類のマージを実行できます。ツリーが1つだけ指定されている場合は単一ツリーマージ、2つのツリーがある場合は早送りマージ、3つ以上のツリーが指定されている場合は3ウェイマージです.
単一ツリーマージ
ツリーが1つだけ指定されている場合、_git read-tree_ は、ユーザーが -m を指定しなかった場合と同様に動作します.ただし、元のインデックスに指定されたパス名に対応するエントリがあり、パスの内容が読み込まれているツリーと一致する場合は、インデックスのstat情報が使用されます. (言い換えれば、インデックスのstat()は、マージされたツリーよりも優先されます).
つまり、git read-tree -m <newtree> の後に git checkout-index -f -u -a を実行すると、_git checkout-index_ は実際に変更されたものだけをチェックアウトします.
これは、_git read-tree_ の後に _git diff-files_ が実行されたときに、不必要な誤検知を回避するために使用されます.
2ツリーマージ
通常、これは git read-tree -m $H $M として呼び出されます。ここで、$H は現在のリポジトリのヘッドコミット、$M は外部ツリーのヘッドであり、$H よりも単純に先に進んでいます（つまり、早送り状況にあります）.
2つのツリーが指定されている場合、ユーザーは _git read-tree_ に次のように指示しています.
-
現在のインデックスと作業ツリーは $H から派生していますが、ユーザーは $H 以降にローカルで変更を加えている可能性があります.
-
ユーザーは $M に早送りしたいと考えています.
この場合、git read-tree -m $H $M コマンドは、この「マージ」の結果としてローカルの変更が失われないようにします。 以下は「繰り越し」ルールです。「I」はインデックス、「clean」はインデックスと作業ツリーが一致していることを意味し、「exists」/「nothing」は指定されたコミットにパスが存在することを指します.
I H M Result
-------------------------------------------------------
0 nothing nothing nothing (does not happen)
1 nothing nothing exists use M
2 nothing exists nothing remove path from index
3 nothing exists exists, use M if "initial checkout",
H == M keep index otherwise
exists, fail
H != M
clean I==H I==M
------------------
4 yes N/A N/A nothing nothing keep index
5 no N/A N/A nothing nothing keep index
6 yes N/A yes nothing exists keep index
7 no N/A yes nothing exists keep index
8 yes N/A no nothing exists fail
9 no N/A no nothing exists fail
10 yes yes N/A exists nothing remove path from index
11 no yes N/A exists nothing fail
12 yes no N/A exists nothing fail
13 no no N/A exists nothing fail
clean (H==M)
------
14 yes exists exists keep index
15 no exists exists keep index
clean I==H I==M (H!=M)
------------------
16 yes no no exists exists fail
17 no no no exists exists fail
18 yes no yes exists exists keep index
19 no no yes exists exists keep index
20 yes yes no exists exists use M
21 no yes no exists exists fail
すべての「インデックスを保持」の場合、インデックスエントリは元のインデックスファイルと同じままです。 エントリが最新でない場合、_git read-tree_ は -u フラグの下で操作しているときに、作業ツリーのコピーをそのまま保持します.
この形式の _git read-tree_ が正常に返された場合、git diff-index --cached $M を実行することで、行った「ローカルの変更」のどれが繰り越されたかを確認できます。 これは、このような2ツリーマージの前に git diff-index --cached $H が生成したものと必ずしも一致するわけではないことに注意してください。 これは、ケース18と19があるためです。$M の変更が既にある場合（たとえば、パッチ形式でメールで受け取った場合）、git diff-index --cached $H はこのマージの前に変更について通知しますが、2ツリーマージの後、git diff-index --cached $M の出力には表示されません.
ケース3はややこしく、説明が必要です。 このルールの論理的な結果は、ユーザーがパスの削除をステージングしてから新しいブランチに切り替えた場合にパスを削除することです。 しかし、これは初期チェックアウトが行われるのを妨げるため、$H と $M が同じである限りパスの削除が維持されるように、インデックスの内容が空の場合にのみ M（新しいツリー）を使用するようにルールが変更されます.
3ウェイマージ
各「インデックス」エントリには、「ステージ」状態を表す2ビットがあります。ステージ0は通常の状態で、通常の使用で目にする唯一のステージです。
ただし、3つのツリーを使用して *git read-tree* を実行すると、「ステージ」は1から始まります。
これは、以下を実行できることを意味します。
$ git read-tree -m <tree1> <tree2> <tree3>
実行すると、<tree1> のすべてのエントリが「ステージ1」に、<tree2> のすべてのエントリが「ステージ2」に、<tree3> のすべてのエントリが「ステージ3」にあるインデックスが作成されます。別のブランチを現在のブランチにマージする場合、共通の祖先ツリーを <tree1> として、現在のブランチヘッドを <tree2> として、もう一方のブランチヘッドを <tree3> として使用します。
さらに、 *git read-tree* には、以下の状態ですべての点で一致するファイルが見つかった場合、「ステージ0」に「折りたたむ」という特別なケースロジックがあります。
-
ステージ2と3が同じ場合。どちらか一方を使用します（違いはありません - ステージ2のブランチとステージ3のブランチで同じ作業が行われています）。
-
ステージ1とステージ2が同じで、ステージ3が異なる場合。ステージ3を使用します（ステージ2のブランチは、ステージ1の祖先から何も変更されていませんが、ステージ3のブランチは変更されています）。
-
ステージ1とステージ3が同じで、ステージ2が異なる場合。ステージ2を使用します（ステージ3のブランチは何も変更されていませんが、ステージ2のブランチは変更されています）。
*git write-tree* コマンドは、無意味なツリーの作成を拒否し、ステージ0ではないエントリが1つでも見つかると、マージされていないエントリについて警告します。
これらはすべて、まったく無意味なルールの集まりのように聞こえますが、実際には高速マージを実行するために必要なものです。異なるステージは、「結果ツリー」（ステージ0、別名「マージ済み」）、元のツリー（ステージ1、別名「orig」）、およびマージしようとしている2つのツリー（それぞれステージ2と3）を表します。
すでにエントリが設定されているインデックスファイルを使用して3方向マージを開始する場合、ステージ1、2、3の順序（したがって、3つの <tree-ish> コマンドライン引数の順序）は重要です。アルゴリズムの動作の概要を以下に示します。
-
ファイルが3つのツリーすべてに同一の形式で存在する場合、 *git read-tree* によって自動的に「マージ済み」状態に折りたたまれます。
-
3つのツリーで *何らかの* 違いがあるファイルは、インデックス内の個別のエントリとして残ります。ステージ0以外を削除し、マージされたバージョンを挿入する方法は、「porcelain policy」によって決定されます。
-
インデックスファイルは、このすべての情報とともに保存および復元されるため、段階的にマージできますが、ステージ1/2/3のエントリ（つまり、「マージされていないエントリ」）がある限り、結果を書き込むことはできません。そのため、マージアルゴリズムは非常にシンプルになります。
-
インデックスを順番に調べて、ステージ0のすべてのエントリを無視します。これらはすでに処理済みであるためです。
-
「ステージ1」が見つかったが、一致する「ステージ2」または「ステージ3」が見つからない場合、そのエントリは両方のツリーから削除された（元のツリーにのみ存在していた）ことがわかります。そのため、そのエントリを削除します。
-
一致する「ステージ2」と「ステージ3」のツリーが見つかった場合は、一方を削除し、もう一方を「ステージ0」エントリに変換します。一致する「ステージ1」エントリが存在する場合は、それも削除します。.. すべての通常の些細なルール ..
-
通常、この最後のステップを実行するには、 *git merge-index* を指定された *git merge-one-file* と一緒に使用します。スクリプトは、各パスをマージする際に、作業ツリー内のファイルを更新し、マージが成功した時点で更新を完了します。
すでに設定されているインデックスファイルを使用して3方向マージを開始する場合、それは作業ツリー内のファイルの状態を表していると想定され、インデックスファイルに記録されていない変更を含むファイルを持つこともできます。さらに、この状態はステージ2ツリーから「派生」したと想定されます。3方向マージは、元のインデックスファイルにステージ2と一致しないエントリが見つかった場合、実行を拒否します。
これは、作業中の変更が失われたり、無関係のマージコミットにランダムな変更が混在したりするのを防ぐためです。例として、リポジトリに最後にコミットされた内容から開始するとします。
$ JC=`git rev-parse --verify "HEAD^0"` $ git checkout-index -f -u -a $JC
*git update-index* を実行せずに、ランダムな編集を行います。その後、「アップストリーム」ツリーの先端が、プルしてから進んでいることに気付きます。
$ git fetch git://.... linus $ LT=`git rev-parse FETCH_HEAD`
作業ツリーは依然としてHEAD（$ JC）に基づいていますが、それ以降にいくつかの編集があります。3方向マージでは、$ JC以降にインデックスエントリを追加または変更していないことを確認し、そうでない場合は正しい処理を行います。そのため、以下のシーケンスを使用すると
$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT $ git merge-index git-merge-one-file -a $ echo "Merge with Linus" | \ git commit-tree `git write-tree` -p $JC -p $LT
コミットされるのは、作業中の変更を含まない$ JCと$ LTの間の純粋なマージであり、作業ツリーはマージの結果に更新されます。
ただし、このマージによって上書きされる作業ツリーにローカルな変更がある場合、 *git read-tree* は変更が失われないように実行を拒否します。
言い換えれば、作業ツリーにのみ存在するものについて心配する必要はありません。マージに関係のないプロジェクトの一部にローカルな変更がある場合、変更はマージに干渉せず、そのまま保持されます。変更が *干渉する* 場合、マージは開始されません（ *git read-tree* は大声で文句を言って、何も変更せずに失敗します）。このような場合は、作業中の作業を続行し、作業ツリーの準備が整ったら（つまり、作業中の作業が完了したら）、マージを再試行するだけです。
スパースチェックアウト
注：git-update-index[1] および `read-tree` の skip-worktree 機能は、git-sparse-checkout[1] の導入よりも前に存在していました。ユーザーは、スパースチェックアウト/ skip-worktree 関連のニーズに対して、これらの plumbing コマンドよりも `sparse-checkout` コマンドを使用することをお勧めします。ただし、以下の情報は、`sparse-checkout` コマンドの非コーンモードで使用されるパターンスタイルを理解しようとしているユーザーにとって役立つ場合があります。
「スパースチェックアウト」を使用すると、作業ディレクトリにファイルをまばらに設定できます。 skip-worktree ビット（git-update-index[1] を参照）を使用して、作業ディレクトリ内のファイルが注目に値するかどうかを Git に指示します。
*git read-tree* およびその他のマージベースのコマンド（ *git merge*、 *git checkout* ...）は、skip-worktree ビットマップと作業ディレクトリの更新を維持するのに役立ちます。 `$GIT_DIR/info/sparse-checkout` は、skip-worktree 参照ビットマップを定義するために使用されます。 *git read-tree* が作業ディレクトリを更新する必要がある場合、.gitignore ファイルと同じ構文を使用するこのファイルに基づいて、インデックス内の skip-worktree ビットをリセットします。エントリがこのファイルのパターンと一致する場合、またはエントリが作業ツリーに存在するファイルに対応する場合、skip-worktree はそのエントリに設定されません。それ以外の場合、skip-worktree が設定されます。
次に、新しい skip-worktree 値を以前の値と比較します。 skip-worktree が設定から設定解除に変わると、対応するファイルが再び追加されます。設定解除から設定に変わると、そのファイルは削除されます。
`$GIT_DIR/info/sparse-checkout` は通常、どのファイルが含まれるかを指定するために使用されますが、否定パターンを使用して、どのファイルが *含まれない* かを指定することもできます。たとえば、ファイル `unwanted` を削除するには、次のようにします。
/* !unwanted
もう1つの注意点は、スパースチェックアウトが不要になったときに作業ディレクトリを完全に再作成することです。 skip-worktree ビットがまだインデックスにあり、作業ディレクトリがまばらに設定されているため、単に「スパースチェックアウト」を無効にすることはできません。 `$GIT_DIR/info/sparse-checkout` ファイルの内容を使用して、次のように作業ディレクトリを再作成する必要があります。
/*
その後、スパースチェックアウトを無効にすることができます。 *git read-tree* および同様のコマンドのスパースチェックアウトサポートは、デフォルトで無効になっています。スパースチェックアウトサポートを有効にするには、`core.sparseCheckout` を有効にする必要があります。
GIT
git[1] スイートの一部
