Git中的FETCH_HEAD是什么意思?

iugsix8n  于 2023-04-28  发布在  Git
关注(0)|答案(8)|浏览(218)

git pull --help说:
在默认模式下,git pullgit fetch后跟git merge FETCH_HEAD的简写。
什么是FETCH_HEAD,在git pull期间实际合并了什么?

ne5o7dgx

ne5o7dgx1#

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,而不需要命名。

wko9yo5t

wko9yo5t2#

FETCH_HEAD是对最后一次提取的提示的引用,无论该提取是直接使用fetch命令还是作为pull的一部分发起的。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
r8uurelv

r8uurelv3#

正如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。奇数是在提取之前 checkout 的分支。总结如下:FETCH_HEAD本质上对应于当前检出的分支的远程版本。

af7jpaap

af7jpaap4#

我刚刚发现并使用了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服务器上使用bug修复编号1234,并让Git的垃圾收集来处理服务器上的副本,一旦修复被挑选到你当前的分支上,这可能是一个很好的方法。(我假设有一个漂亮的干净的标记提交,包含服务器上的整个bug修复!)

ybzsozfc

ybzsozfc5#

FETCH_HEAD是一个短暂的引用,用于跟踪刚刚从远程存储库获取的内容。
事实上....不总是 * 考虑到这一点,Git 2。29(2020年第4季度),“git fetch”(man)学习了--no-write-fetch-head选项,以避免写入FETCH_HEAD文件。
参见commit 887952b(2020年8月18日)。
(由Junio C Hamano -- gitster --合并到commit b556050,2020年8月24日)

fetch:可选地允许禁用FETCH_HEAD更新

签字人:德里克·斯托利
如果你运行fetch但在远程跟踪分支中记录结果,或者如果你对所获取的引用不做任何事情(例如:例如,你只是镜像)或者如果你总是从远程跟踪参考工作(例如。例如,您单独获取然后合并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现在在其手册页中包括:

--[no-]write-fetch-head

FETCH_HEAD文件中获取的远程引用列表直接写入$GIT_DIR下。
这是默认值。
从命令行传递--no-write-fetch-head,告诉Git不要写入文件。
--dry-run选项下,永远不会写入文件。
再看看Git 2。29(2020年第4季度),FETCH_HEAD现在总是从文件系统读取,而不管使用的ref后端如何,因为它的格式比普通ref丰富得多,并且直接由“git fetch”(man)作为普通文件写入。.
参见commit e811530commit 5085aefcommit 4877c6ccommit e39620f(2020年8月19日)by Han-Wen Nienhuys ( hanwen )
(由Junio C Hamano -- gitster --合并至commit 98df75b,2020年8月27日)

refs:一般读取FETCH_HEADMERGE_HEAD

签字人:汉文·尼恩休斯
FETCH_HEADMERGE_HEAD引用必须存储在一个文件中,无论引用后端的类型如何。这是因为它们可以容纳不止一个引用
为了使它们适应备用的ref后端,可以从一个文件中读取它们,一般是refs_read_raw_ref()
随着Git 2.29(2020年第4季度),更新到延迟克隆存储库中的按需获取代码。
参见commit db3c293(2020年9月2日)和commit 9dfa8dbcommit 7ca3c0acommit 5c3b801commit abcb7eecommit e5b9421commit 2b713c2commit cbe566a(2020年8月17日)by Jonathan Tan ( jhowtan )
(由Junio C Hamano -- gitster --合并至commit b4100f3,2020年9月3日)

fetch:no FETCH_HEAD display if --no-write-fetch-head

签字人:陈宗泽
887952b8c6(“fetch:optionally allow disable FETCH_HEAD update”,2020-08-18,Git v2.29.0 --batch #10中列出的merge)引入了在提取期间禁止写入FETCH_HEAD的功能,但在使用此功能时没有抑制“<source> -> FETCH_HEAD"”消息。
在这种情况下,此消息具有误导性,因为FETCH_HEAD未写入。
此外,因为“fetch”用于延迟获取部分克隆中丢失的对象,所以在这种情况下,由于要获取的对象可能很多,这会显著地扰乱输出。
因此,当--no-write-fetch-head被传递时(而不是--dry-run被设置时),禁止此消息。
在Git 2.41(2023年第2季度)中,此选项被正确传播:
参见commit 15184ae(2023年3月8日),作者Eric Wong ( ele828 )
(由Junio C Hamano -- gitster --合并于commit 947604d,2023年3月19日)

fetch:将--no-write-fetch-head传递给子进程

签字人:黄耀威
看起来,用户希望这个选项能够工作,无论它是从单个远程获取,多个远程获取,还是递归到子模块中。

e1xvtsh3

e1xvtsh36#

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

bzzcjhmw

bzzcjhmw7#

如果可能的话,让我为此作出贡献。
1.在图像上,我已经要求远程,如果有一些变化,在分支,我正在工作。FETCH告诉我 * 分支back_end -〉FETCH_HEAD
1.然后,我请求PULL,试图将REMOTE(GITHUB)上的所有新内容带到我的本地分支(它有相同的名称back_end)
GIT告诉我---〉〉FETCH_HEAD,这意味着所有内容都已经更新,并且有任何内容需要从REMOTE分支更新,与FETCH指令之前告诉我的信息相同。

a9wyjsp7

a9wyjsp78#

我只是试图拉下一个(补丁)分支,我直接从GitHub进行更改创建。该分支只出现在GH上。当我试着做一个G拉,分支没有出现。
我可以使用以下命令来 checkout 分支:

git fetch origin pull/2/head
git checkout -b <desired-branch-name> FETCH_HEAD

相关问题