Git中的FETCH_HEAD是什么意思？

Question

git pull --help说：

  

在默认模式下，git pull是git fetch的简写，后跟git merge FETCH_HEAD。

这是FETCH_HEAD的内容，以及git pull期间实际合并的内容？

Answer 1

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来引用无论是什么单一的参考，而不是需要命名。

Answer 2

FETCH_HEAD是对最后一次提取的提示的引用，无论该提取是使用fetch命令直接启动还是作为pull的一部分启动。 FETCH_HEAD的当前值存储在名为.git的{​​{1}}文件夹中，您猜对了，FETCH_HEAD。

所以，如果我发出：

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

FETCH_HEAD可能包含

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

如果我将远程仓库配置为远程跟踪分支，那么我可以通过合并跟踪分支来跟踪我的提取。如果我不这样做，我可以直接使用FETCH_HEAD合并最后一次获取的提示。

git merge FETCH_HEAD

Answer 3

如Jonathan's answer中所述，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>

请注意除了一个分支以外的所有分支都标记为not-for-merge。奇怪的是在获取之前检出的分支。总结：FETCH_HEAD基本上对应于当前检出的分支的远程版本。

Answer 4

我刚刚发现并使用了FETCH_HEAD。我想从服务器获得一些软件的本地副本，我做了

git fetch gitserver release_1

gitserver是存储git存储库的计算机的名称。 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。 （这是来源：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的垃圾收集器从服务器中处理掉。 （我假设有一个很好的干净标记提交，包含服务器上的整个错误修复！）

Answer 5

git pull是fetch后跟合并的组合。当git fetch发生时，它会记录它在FETCH_HEAD中获取的内容的提交（只是.git中该名称的文件）然后这些提交将合并到您的工作目录中。

Answer 6

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

实际上，...并非总是 考虑到在Git 2.29（2020年第四季度）中，“ git fetch” ^（man） --no-write-fetch-head选项可避免写入FETCH_HEAD文件。

请参见commit 887952b的Junio C Hamano (gitster)（2020年8月18日）。
^{（由Junio C Hamano -- gitster --在commit b556050中合并，2020年8月24日）}

fetch ：（可选）禁用FETCH_HEAD更新

^{签名人：Derrick Stolee}

如果您运行fetch但将结果记录在远程跟踪分支中，或者如果您对获取的ref不执行任何操作（例如，您只是镜像），或者始终使用远程跟踪ref（例如，获取和然后分别合并origin/branchname），则可以完全不用FETCH_HEAD。

教“ git fetch” ^（man）命令行选项“ --[no-]write-fetch-head”。

• 默认为写入FETCH_HEAD,，并且该选项主要用于与“ --no-”前缀一起使用以覆盖此默认值，因为没有匹配的fetch.writeFetchHEAD配置变量将默认设置关闭（在这种情况下，可能需要使用肯定形式来击败它）。

请注意，在“ --dry-run”模式下，FETCH_HEAD不会被写入；否则，您会看到文件中实际上没有的对象列表。

传递--write-fetch-head不会强制[ git fetch ](https://github.com/git/git/blob/887952b8c680626f4721cb5fa57704478801aca4/Documentation/git-fetch.txt)<sup>([man](https://git-scm.com/docs/git-fetch))</sup>写入文件。

fetch-options现在包含在其man page中：

--[no-]write-fetch-head

在FETCH_HEAD下的$GIT_DIR文件中写入获取的远程引用列表。
这是默认设置。

从命令行传递--no-write-fetch-head告诉 git不要写文件。
在--dry-run选项下，永远不会写入文件。

---

还要考虑，仍然使用Git 2.29（2020年第四季度），现在FETCH_HEAD始终可以从文件系统中读取，无论使用的是哪种ref后端，因为其格式比普通ref丰富得多，并且可以直接写入通过“ git fetch” ^（man）作为普通文件。

请参见commit e811530的commit 5085aef，commit 4877c6c，commit e39620f，Han-Wen Nienhuys (hanwen)（2020年8月19日）。
^{（由Junio C Hamano -- gitster --在commit 98df75b中合并，2020年8月27日）}

refs：大致阅读FETCH_HEAD和MERGE_HEAD

^{签名人：Han-Wen Nienhuys}

无论引用后端的类型如何，FETCH_HEAD和MERGE_HEAD引用都必须存储在文件中。 这是因为他们不仅仅可以容纳一个裁判。

要适应备用参考后端，请从refs_read_raw_ref()中的文件中读取它们。

---

使用Git 2.29（2020年第四季度），更新了延迟克隆存储库中的按需获取代码。

请参见commit db3c293（2020年9月2日）以及commit 9dfa8db，commit 7ca3c0a，commit 5c3b801，commit abcb7ee，commit e5b9421，{{3} }，commit 2b713c2（2020年8月17日）通过commit cbe566a。
^{（由Jonathan Tan (jhowtan)在Junio C Hamano -- gitster --中合并，2020年9月3日）}

commit b4100f3：如果--no-write-fetch-head不显示FETCH_HEAD

^{签名人：Jonathan Tan}

fetch（“ fetch：可选地允许禁用FETCH_HEAD更新”，2020-08-18，{{3} }）引入了在提取过程中禁止写入FETCH_HEAD的功能，但是在使用此功能时并未抑制“ <source> -> FETCH_HEAD"”消息。

在这种情况下，此消息具有误导性，因为未写FETCH_HEAD。

此外，由于使用“ fetch”来延迟获取部分克隆中的丢失对象，因此在这种情况下，由于要获取的对象可能很多，因此这会极大地混淆输出。

因此，在传递--no-write-fetch-head时禁止显示此消息（但在设置--dry-run时则不显示）。