我读到here git FETCH_HEAD是一个短命引用。 git FETCH_HEAD参考的生命是什么？
当我执行git fetch origin时，在这种情况下会更新许多远程跟踪分支。 FETCH_HEAD指向哪里？
答案 0 :(得分：3)
这根本不是真正的参考;引用是指向单个提交的指针（或者，在HEAD的情况下，是一个分支名称）。 FETCH_HEAD是关于上次提取的分支的git元数据。它一直存在，直到它被另一个 fetch
这不是真正的参考，并且包含所有有关所提取的远程跟踪信息的信息。
当您运行git merge FETCH_HEAD（或通过运行git pull隐式执行此操作）时，git会特别处理此问题，而不是正常引用。相反，将查询FETCH_HEAD文件，git将查找没有给予特殊标记not-for-merge的分支。该分支将是用于合并的分支。 （Git根据您的git fetch调用对应的远程跟踪分支或您运行它时所在的分支确定了此分支。）
请注意，在FETCH_HEAD中，还包括有关远程分支的详细信息，这允许git为合并提交创建一条消息，详细说明 该分支来自何处。 （例如，“Merge of branch 'master' of https://my.visualstudio.com/my/repository”）。
FETCH_HEAD只是一个文本文件;阅读它以了解每次获取后它是如何变化的令人难以置信的亮点。 （例如，您可以看到，您链接到的答案非常不正确，FETCH_HEAD 不包含单个分支的信息，它包含 all 遥控器上的分支。）
答案 1 :(得分：2)
如gitrevisions中所说，
FETCH_HEAD记录您从远程获取的分支 存储库与您上次的git fetch调用。
FETCH_HEAD由第一个git fetch创建，并由git fetch更新。截至git fetch，它还意味着git pull，因为git pull可以是git fetch + git merge或git fetch + git rebase。
对于git fetch origin foo，毫无疑问FETCH_HEAD指向foo的提示。 foo是可以从远程存储库获取的有效引用。在极少数情况下，foo可以是特定对象（提交，树，blob或标记）的哈希值，如果在远程存储库中设置uploadpack.allowTipSHA1InWant true，然后{{1}将指向该对象。
FETCH_HEAD或git fetch变得复杂。 git fetch origin将更新为什么？有很多情况。例如，本地存储库位于分离的HEAD中，在具有上游的特定分支上，在没有上游的分支上，或者在某些其他情况下。如果不深入挖掘，我们可以从FETCH_HEAD的输出中得知结果。这是一个样本，
git fetch我们可以看到输出说明remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 7), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From D:/hello
ca2d63e..38d365c ost -> origin/ost
* [new branch] a -> origin/a
8fe4b12..db5a0d9 aaa -> origin/aaa
36ca690..e00229b haha -> origin/haha
c96b459..5ab6097 master -> origin/master
283a081..004375e mist -> origin/mist
更新了哪些引用。 git fetch始终指向第一个参考小费。在此示例中，FETCH_HEAD是FETCH_HEAD的提示，origin/ost。只获取一个ref或一个对象时也是如此。
如果38d365c进程失败，git fetch将成为未知修订版。文件FETCH_HEAD仍然存在，而且它只是空的。