FETCH_HEAD是一个短命的引用，用于跟踪刚刚从远程存储库获取的内容。Git pull首先调用Git fetch，在正常情况下从远程获取一个分支;FETCH_HEAD指向这个分支的顶端(它存储提交的SHA1，就像分支一样)。git pull然后调用git merge，将FETCH_HEAD合并到当前分支。

结果正是您所期望的:适当远程分支顶端的提交合并到当前分支顶端的提交。

这有点像不带参数的git获取(或git远程更新)，更新所有远程分支，然后运行git merge origin/<branch>，但在内部使用FETCH_HEAD来引用所获取的任何单个引用，而不需要命名东西。

如果可能的话，让我为之贡献力量。

在图像上，我已经向REMOTE询问了我正在工作的分支是否有一些变化。 FETCH已经告诉我*分支后台-> FETCH_HEAD 然后我要求拉，试图把所有新的远程(GITHUB)到我的本地分支(它有相同的名字back_end)

GIT告诉我——>> FETCH_HEAD，这意味着所有东西都已经更新了，有任何东西要从REMOTE BRANCH更新，与FETCH指令之前告诉我的信息相同。

FETCH_HEAD是对最后一次获取的尖端的引用，无论该获取是直接使用fetch命令启动的，还是作为拉取的一部分。FETCH_HEAD的当前值存储在。git文件夹中一个名为FETCH_HEAD的文件中。

所以如果我发出:

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

FETCH_HEAD可以包含

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

如果我将远程回购配置为远程跟踪分支，那么我可以使用跟踪分支的合并来跟踪我的fetch。如果我不这样做，我可以合并尖端的最后获取直接使用FETCH_HEAD。

git merge FETCH_HEAD

FETCH_HEAD是一个短命的引用，用于跟踪刚刚从远程存储库获取的内容。

实际上,…并不总是考虑到这一点，在Git 2.29 (Q4 2020)中，“Git fetch”(man)学会了—no-write-fetch-head选项，以避免写入FETCH_HEAD文件。

参见juno C Hamano (gitster)提交的887952b(2020年8月18日)。 (由Junio C Hamano—gitster—在commit b556050中合并，2020年8月24日)

fetch:可选允许禁用FETCH_HEAD更新 署名:Derrick Stolee

If you run fetch but record the result in remote-tracking branches, and either if you do nothing with the fetched refs (e.g. you are merely mirroring) or if you always work from the remote-tracking refs (e.g. you fetch and then merge origin/branchname separately), you can get away with having no FETCH_HEAD at all. Teach "git fetch"(man) a command line option "--[no-]write-fetch-head". The default is to write FETCH_HEAD, and the option is primarily meant to be used with the "--no-" prefix to override this default, because there is no matching fetch.writeFetchHEAD configuration variable to flip the default to off (in which case, the positive form may become necessary to defeat it). Note that under "--dry-run" mode, FETCH_HEAD is never written; otherwise you'd see list of objects in the file that you do not actually have. Passing --write-fetch-head does not force [git fetch](https://github.com/git/git/blob/887952b8c680626f4721cb5fa57704478801aca4/Documentation/git-fetch.txt)^{([man](https://git-scm.com/docs/git-fetch))} to write the file.

Fetch-options现在包含在它的手册页中:

——不——write-fetch-head 直接在$GIT_DIR下写入FETCH_HEAD文件中获取的远程引用列表。 这是默认值。 从命令行传递——no-write-fetch-head告诉 Git不写文件。 在——dry-run选项下，文件永远不会被写入。

再考虑一下，仍然使用Git 2.29 (Q4 2020)， FETCH_HEAD现在总是从文件系统中读取，而不管使用的是ref后端，因为它的格式比普通的ref丰富得多，并且直接由“Git fetch”(man)作为一个普通文件写入。

参见hanwen Nienhuys (hanwen)的commit e811530, commit 5085aef, commit 4877c6c, commit e39620f (19 Aug 2020)。 (由Junio C Hamano—gitster—在commit 98df75b中合并，2020年8月27日)

参考:读取FETCH_HEAD和MERGE_HEAD一般 签署人:Han-Wen Nienhuys

FETCH_HEAD和MERGE_HEAD引用必须存储在文件中，无论引用后端是什么类型。这是因为它们可以容纳不止一个裁判。 为了将它们用于备用的ref后端，一般从refs_read_raw_ref()中的文件中读取它们。

在Git 2.29 (Q4 2020)中，更新到惰性克隆存储库中的按需抓取代码。

参见Jonathan Tan (jhowtan)的commit db3c293 (02 Sep 2020)， and commit 9dfa8db, commit 7ca3c0a, commit 5c3b801, commit abcb7ee, commit e5b9421, commit 2b713c2, commit cbe566a (2020 Aug 17)。 (由Junio C Hamano - gitster - in commit b4100f3, 03 Sep 2020)

fetch:不显示FETCH_HEAD如果——no-write-fetch-head 署名:乔纳森·谭

887952b8c6 ("fetch: optionally allow disabling FETCH_HEAD update", 2020-08-18, Git v2.29.0 -- merge listed in batch #10) introduced the ability to disable writing to FETCH_HEAD during fetch, but did not suppress the "<source> -> FETCH_HEAD" message when this ability is used. This message is misleading in this case, because FETCH_HEAD is not written. Also, because "fetch" is used to lazy-fetch missing objects in a partial clone, this significantly clutters up the output in that case since the objects to be fetched are potentially numerous. Therefore, suppress this message when --no-write-fetch-head is passed (but not when --dry-run is set).

FETCH_HEAD是一个短命的引用，用于跟踪刚刚从远程存储库获取的内容。Git pull首先调用Git fetch，在正常情况下从远程获取一个分支;FETCH_HEAD指向这个分支的顶端(它存储提交的SHA1，就像分支一样)。git pull然后调用git merge，将FETCH_HEAD合并到当前分支。

结果正是您所期望的:适当远程分支顶端的提交合并到当前分支顶端的提交。

这有点像不带参数的git获取(或git远程更新)，更新所有远程分支，然后运行git merge origin/<branch>，但在内部使用FETCH_HEAD来引用所获取的任何单个引用，而不需要命名东西。

Git pull是一个fetch和merge的组合。当git获取发生时，它会注意到它在FETCH_HEAD中获取的内容的头提交(只是一个在.git中同名的文件)，然后这些提交被合并到你的工作目录中。