GitのFETCH_HEADはどういう意味ですか？

git pull --help 言う：

デフォルトモードでgit pullは、はのgit fetch後に続く省略形ですgit merge FETCH_HEAD。

これは何ですか？FETCH_HEAD実際に何がマージされgit pullますか？

FETCH_HEADリモートリポジトリからフェッチされたばかりの内容を追跡する、存続期間の短い参照です。git pull最初にを呼び出しますgit fetch。通常はリモートからブランチをフェッチします。FETCH_HEADこのブランチの先端を指します（ブランチのように、コミットのSHA1を格納します）。git pull次にを呼び出しgit merge、FETCH_HEAD現在のブランチにマージします。

結果はまさに期待どおりです。適切なリモートブランチの先端にあるコミットが、現在のブランチの先端にあるコミットにマージされます。

これは少しやってようであるgit fetch引数なし（またはgit remote update）、すべてのリモートブランチを更新し、その後、実行しているgit merge origin/<branch>が、使用してFETCH_HEADどのような単一のREFを参照する代わりに、内部的には、代わりのものに名前を付けるために必要で、フェッチされました。

FETCH_HEADは、フェッチがフェッチコマンドを使用して直接開始されたか、プルの一部として開始されたかに関係なく、最後のフェッチのヒントへの参照です。FETCH_HEADの現在の値は.git、あなたが推測した名前のファイル内のフォルダーに保存されますFETCH_HEAD。

だから私が発行した場合：

git fetch https://github.com/ryanmaxwell/Fragaria

FETCH_HEADには

3cfda7cfdcf9fb78b44d991f8470df56723658d3        https://github.com/ryanmaxwell/Fragaria

リモートリポジトリをリモートトラッキングブランチとして構成している場合は、フェッチの後にトラッキングブランチをマージすることができます。そうでない場合は、FETCH_HEADを使用して、最後のフェッチのヒントを直接マージできます。

git merge FETCH_HEAD

ジョナサンの回答で述べたように、FETCH_HEADはファイルに対応します.git/FETCH_HEAD。通常、ファイルは次のようになります。

71f026561ddb57063681109aadd0de5bac26ada9                        branch 'some-branch' of <remote URL>
669980e32769626587c5f3c45334fb81e5f44c34        not-for-merge   branch 'some-other-branch' of <remote URL>
b858c89278ab1469c71340eef8cf38cc4ef03fed        not-for-merge   branch 'yet-some-other-branch' of <remote URL>

1つを除くすべてのブランチがマークされてnot-for-mergeいることに注意してください。奇妙なのは、フェッチの前にチェックアウトされたブランチです。要約すると、FETCH_HEADは基本的に、現在チェックアウトされているブランチのリモートバージョンに対応しています。

私は発見して使用しましたFETCH_HEAD。サーバーから一部のソフトウェアのローカルコピーが必要でした。

git fetch gitserver release_1

gitservergitリポジトリを保存する私のマシンの名前です。 release_1ソフトウェアのバージョンのタグです。驚いたことに、そのときrelease_1私のローカルマシンにはどこにも見つかりませんでした。入力しなければならなかった

 git tag release_1 FETCH_HEAD 

タグ付けされたコミットのチェーン（release_1）のコピーをリモートリポジトリからローカルリポジトリに完了する。Fetchはリモートタグを見つけ、ローカルマシンにコミットをコピーしましたが、ローカルタグを作成していませんFETCH_HEADが、コミットの値を設定していたので、それを見つけて使用できました。次にFETCH_HEAD、リモートのタグと一致するローカルタグを作成するために使用しました。これは、何FETCH_HEADがどのように使用できるかを示す実際的な例であり、git fetchが単純に期待したことを実行しないのはなぜかと疑問に思っている他のユーザーにとって役立つ場合があります。

私の意見では、それはその目的のために避けるのが最善であり、私がやろうとしていたことを達成するためのより良い方法は

git fetch gitserver release_1:release_1

つまり、release_1をフェッチして、それをrelease_1とローカルに呼び出します。（source：destです。https：//git-scm.com/book/en/v2/Git-Internals-The-Refspecを参照してくださいです。別の名前を付けたい場合に備えてください。）

FETCH_HEADしかし、時々使用したいかもしれません：-

git fetch gitserver bugfix1234
git cherry-pick FETCH_HEAD

Gitサーバーからバグ修正番号1234を使用し、修正が現在のブランチに適切に選択されたら、Gitのガベージコレクションを残してサーバーからのコピーを破棄する良い方法かもしれません。（私は、サーバー上のバグ修正のすべてを含む、きれいなタグ付けされたコミットがあると想定しています！）

git pullは、フェッチとそれに続くマージの組み合わせです。git fetchが発生すると、FETCH_HEADでフェッチした内容のヘッドコミット（.git内のその名前のファイルのみ）が記録され、これらのコミットが作業ディレクトリにマージされます。