这主要是好奇心的本质,因为我正在努力熟悉Git。我查看了'git fetch'的文档,但我没有看到下面的明显解释。在此先感谢,如果这是显而易见的,请道歉。
1)从中央存储库,比如说GitHub,我在两台机器website
和HostA
的每台机器上克隆一个名为HostB
的存储库。
2)在HostA
上,我对文件进行了更改,说出README.txt
,然后提交。
此时HostA
上的分支master
和。{
正如预期的那样,origin/master
是不同的,因为我还没推动
git show master
git show origin/master
报告不同的哈希值(因为master
有更改而origin/master
没有)
3)一旦我推,他们就是在那之后。
4)现在,在HostB
上,如果我执行以下操作:
git fetch
git merge FETCH_HEAD
之后,HostB master
和origin/master
在使用git show
BUT
如果我已经完成了,请HostB
:
git fetch origin master
git merge FETCH_HEAD
此时哈希仍然不同。
git show origin
git show origin/master
报告不同的哈希
跟踪分支origin/master
在我执行普通git fetch
为什么会这样?
答案 0 :(得分:23)
如果您的分支有关联的remote tracking branch,则表示其配置如下:
git config branch.[branch-name].remote [remote-name]
git config branch.[branch-name].merge [remote-master]
解释两个命令之间差异的 git fetch
的关键部分是:
<refspec>
<refspec>
参数的格式是可选加+
,后跟源引用<src>
,后跟冒号:
,后跟目标引用{ {1}}。
提取匹配<dst>
的远程引用,如果<src>
不是空字符串,则使用<dst>
快速转发与其匹配的本地引用。< / p>
让我重复一遍:
如果<src>
不是空字符串,则使用<dst>
快速转发与其匹配的本地参考号。
知道:
<src>
相当于 git fetch
(来自分支配置的默认值),因此会更新远程跟踪分支:为您指定refspec的目的地。
git fetch origin master:master
相当于“git fetch origin master
”,而不是“git fetch origin master:
”;它将“git fetch origin master:master
”分支(远程“master
”)的获取值存储在origin
中,而不是“FETCH_HEAD
”分支或远程跟踪'{{1 }}'分支(来自Jakub Narębski的answer)
换句话说,您未指定refspec的目的地
答案 1 :(得分:0)
答案取决于您从git fetch
收到的消息。在第一种情况下,当您提取而不提供refspec时,您将看到远程跟踪分支已更新:
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /depot
c67d1c8..1941673 master -> origin/master
请注意该消息如何使用来自原点的主数据更新原点/主数据。
现在在第二种情况下,你指定了refspec,你会得到一些完全不同的东西:
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /depot
* branch master -> FETCH_HEAD
因此,当您指定refspec时,远程跟踪分支(origin / master)不会更新,只会更新FETCH_HEAD。
最终的结果是,当你不是真的时,你似乎会领先于原点/主人。我无法想象为什么这种行为是可取的,但它肯定是fetch命令的一个有趣的小怪癖。
答案 2 :(得分:0)
如果你想快速合并自己,或者使用git pull。您似乎不明白git fetch的目的不是更新您的工作树。 Fetch旨在更新您的跟踪分支。