git pull --help说:在默认模式下,git pull是git fetch后跟git merge FETCH_HEAD的简写。什么是FETCH_HEAD,在git pull期间实际合并了什么?
git pull --help
git pull
git fetch
git merge FETCH_HEAD
FETCH_HEAD
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,而不需要命名。
git merge
git remote update
git merge origin/<branch>
wko9yo5t2#
FETCH_HEAD是对最后一次提取的提示的引用,无论该提取是直接使用fetch命令还是作为pull的一部分发起的。FETCH_HEAD的当前值存储在.git文件夹中,您猜对了,这个文件名为FETCH_HEAD。所以如果我发出:
.git
git fetch https://github.com/ryanmaxwell/Fragaria
FETCH_HEAD可能包含
3cfda7cfdcf9fb78b44d991f8470df56723658d3 https://github.com/ryanmaxwell/Fragaria
如果我将远程存储库配置为远程跟踪分支,那么我可以在获取之后合并跟踪分支。如果我不这样做,我可以直接使用FETCH_HEAD合并最后一次提取的提示。
r8uurelv3#
正如Jonathan's answer中提到的,FETCH_HEAD对应于文件.git/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本质上对应于当前检出的分支的远程版本。
not-for-merge
af7jpaap4#
我刚刚发现并使用了FETCH_HEAD。我想要一个本地副本的一些软件从服务器上,我做到了
git fetch gitserver release_1
gitserver是存储git仓库的机器的名称。release_1是软件版本的标记。令我惊讶的是,在我的本地机器上找不到release_1。我不得不打字
gitserver
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修复!)
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日)
--no-write-fetch-head
gitster
fetch
签字人:德里克·斯托利如果你运行fetch但在远程跟踪分支中记录结果,或者如果你对所获取的引用不做任何事情(例如:例如,你只是镜像)或者如果你总是从远程跟踪参考工作(例如。例如,您单独获取然后合并origin/branchname),您可以摆脱根本没有FETCH_HEAD的情况。示教“git fetch”(man)命令行选项“--[no-]write-fetch-head”。
origin/branchname
--[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现在在其手册页中包括:
--dry-run
--write-fetch-head
[
](https://github.com/git/git/blob/887952b8c680626f4721cb5fa57704478801aca4/Documentation/git-fetch.txt)<sup>([man](https://git-scm.com/docs/git-fetch))</sup>
fetch-options
将FETCH_HEAD文件中获取的远程引用列表直接写入$GIT_DIR下。这是默认值。从命令行传递--no-write-fetch-head,告诉Git不要写入文件。在--dry-run选项下,永远不会写入文件。再看看Git 2。29(2020年第4季度),FETCH_HEAD现在总是从文件系统读取,而不管使用的ref后端如何,因为它的格式比普通ref丰富得多,并且直接由“git fetch”(man)作为普通文件写入。.参见commit e811530,commit 5085aef,commit 4877c6c,commit e39620f(2020年8月19日)by Han-Wen Nienhuys ( hanwen )。(由Junio C Hamano -- gitster --合并至commit 98df75b,2020年8月27日)
$GIT_DIR
hanwen
refs
MERGE_HEAD
签字人:汉文·尼恩休斯FETCH_HEAD和MERGE_HEAD引用必须存储在一个文件中,无论引用后端的类型如何。这是因为它们可以容纳不止一个引用。为了使它们适应备用的ref后端,可以从一个文件中读取它们,一般是refs_read_raw_ref()。随着Git 2.29(2020年第4季度),更新到延迟克隆存储库中的按需获取代码。参见commit db3c293(2020年9月2日)和commit 9dfa8db、commit 7ca3c0a、commit 5c3b801、commit abcb7ee、commit e5b9421、commit 2b713c2、commit cbe566a(2020年8月17日)by Jonathan Tan ( jhowtan )。(由Junio C Hamano -- gitster --合并至commit b4100f3,2020年9月3日)
refs_read_raw_ref()
jhowtan
签字人:陈宗泽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日)
<source> -> FETCH_HEAD"
ele828
签字人:黄耀威看起来,用户希望这个选项能够工作,无论它是从单个远程获取,多个远程获取,还是递归到子模块中。
e1xvtsh36#
git pull是fetch和merge的组合。当git fetch发生时,它会记录它在FETCH_HEAD中获取的内容的头部提交(只是一个同名的文件。git)然后这些提交被合并到你的工作目录中。
bzzcjhmw7#
如果可能的话,让我为此作出贡献。1.在图像上,我已经要求远程,如果有一些变化,在分支,我正在工作。FETCH告诉我 * 分支back_end -〉FETCH_HEAD1.然后,我请求PULL,试图将REMOTE(GITHUB)上的所有新内容带到我的本地分支(它有相同的名称back_end)GIT告诉我---〉〉FETCH_HEAD,这意味着所有内容都已经更新,并且有任何内容需要从REMOTE分支更新,与FETCH指令之前告诉我的信息相同。
a9wyjsp78#
我只是试图拉下一个(补丁)分支,我直接从GitHub进行更改创建。该分支只出现在GH上。当我试着做一个G拉,分支没有出现。我可以使用以下命令来 checkout 分支:
git fetch origin pull/2/head git checkout -b <desired-branch-name> FETCH_HEAD
8条答案
按热度按时间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,而不需要命名。wko9yo5t2#
FETCH_HEAD是对最后一次提取的提示的引用,无论该提取是直接使用fetch命令还是作为pull的一部分发起的。FETCH_HEAD的当前值存储在
.git
文件夹中,您猜对了,这个文件名为FETCH_HEAD
。所以如果我发出:
FETCH_HEAD可能包含
如果我将远程存储库配置为远程跟踪分支,那么我可以在获取之后合并跟踪分支。如果我不这样做,我可以直接使用FETCH_HEAD合并最后一次提取的提示。
r8uurelv3#
正如Jonathan's answer中提到的,FETCH_HEAD对应于文件
.git/FETCH_HEAD
。通常,文件看起来像这样:请注意,除了一个分支外,所有分支都标记为
not-for-merge
。奇数是在提取之前 checkout 的分支。总结如下:FETCH_HEAD本质上对应于当前检出的分支的远程版本。af7jpaap4#
我刚刚发现并使用了
FETCH_HEAD
。我想要一个本地副本的一些软件从服务器上,我做到了gitserver
是存储git仓库的机器的名称。release_1
是软件版本的标记。令我惊讶的是,在我的本地机器上找不到release_1
。我不得不打字以完成将***标记的提交链***(release_1)从远程存储库复制到本地存储库。Fetch已经找到了远程标记,将提交复制到我的本地机器上,没有创建本地标记,但将
FETCH_HEAD
设置为提交的值,以便我可以找到并使用它。然后我使用FETCH_HEAD
创建一个本地标记,它与远程标记相匹配。这是一个关于FETCH_HEAD
是什么以及如何使用它的实际说明,对于其他想知道为什么git fetch没有做你天真期望的事情的人来说可能很有用。在我看来,最好是避免为了这个目的,一个更好的方法来实现我试图做的事情是
即获取release_1并在本地调用它release_1。(源代码:dest,参见https://git-scm.com/book/en/v2/Git-Internals-The-Refspec;如果你想给予它一个不同的名字!)
您可能需要在某些时候使用
FETCH_HEAD
:从你的Git服务器上使用bug修复编号1234,并让Git的垃圾收集来处理服务器上的副本,一旦修复被挑选到你当前的分支上,这可能是一个很好的方法。(我假设有一个漂亮的干净的标记提交,包含服务器上的整个bug修复!)
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 e811530,commit 5085aef,commit 4877c6c,commit e39620f(2020年8月19日)by Han-Wen Nienhuys (
hanwen
)。(由Junio C Hamano --
gitster
--合并至commit 98df75b,2020年8月27日)refs
:一般读取FETCH_HEAD
和MERGE_HEAD
签字人:汉文·尼恩休斯
FETCH_HEAD
和MERGE_HEAD
引用必须存储在一个文件中,无论引用后端的类型如何。这是因为它们可以容纳不止一个引用。为了使它们适应备用的ref后端,可以从一个文件中读取它们,一般是
refs_read_raw_ref()
。随着Git 2.29(2020年第4季度),更新到延迟克隆存储库中的按需获取代码。
参见commit db3c293(2020年9月2日)和commit 9dfa8db、commit 7ca3c0a、commit 5c3b801、commit abcb7ee、commit e5b9421、commit 2b713c2、commit cbe566a(2020年8月17日)by Jonathan Tan (
jhowtan
)。(由Junio C Hamano --
gitster
--合并至commit b4100f3,2020年9月3日)fetch
:noFETCH_HEAD
display if --no-write-fetch-head签字人:陈宗泽
887952b8c6(“
fetch
:optionally allow disableFETCH_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
传递给子进程签字人:黄耀威
看起来,用户希望这个选项能够工作,无论它是从单个远程获取,多个远程获取,还是递归到子模块中。
e1xvtsh36#
git pull是fetch和merge的组合。当git fetch发生时,它会记录它在FETCH_HEAD中获取的内容的头部提交(只是一个同名的文件。git)然后这些提交被合并到你的工作目录中。
bzzcjhmw7#
如果可能的话,让我为此作出贡献。
1.在图像上,我已经要求远程,如果有一些变化,在分支,我正在工作。FETCH告诉我 * 分支back_end -〉FETCH_HEAD
1.然后,我请求PULL,试图将REMOTE(GITHUB)上的所有新内容带到我的本地分支(它有相同的名称back_end)
GIT告诉我---〉〉FETCH_HEAD,这意味着所有内容都已经更新,并且有任何内容需要从REMOTE分支更新,与FETCH指令之前告诉我的信息相同。
a9wyjsp78#
我只是试图拉下一个(补丁)分支,我直接从GitHub进行更改创建。该分支只出现在GH上。当我试着做一个G拉,分支没有出现。
我可以使用以下命令来 checkout 分支: