使用git并希望从服务器获取更改时的约定是:
git fetch
git merge origin/master
我知道还有git pull
,但我的具体问题是语法origin/master
。 master
部分做了什么?如果我只是git merge origin
(没有master
),它似乎有效。我知道master
是一个分支,但如果我正在跟踪一个以上的分支,那么正常的用例是否会合并所有分支?
答案 0 :(得分:4)
如果未指定分支,git merge origin
将合并在origin
远程(通常为master
)的默认分支中。在这种情况下,git merge origin
和git merge origin/master
会做同样的事情。但是,如果要在origin
的其他分支中进行合并,则必须指定分支。
答案 1 :(得分:4)
merge
的参数被解析为commit-ID。这意味着应用了gitrevisions中的规则。通常,origin/name
会解析为git fetch
和git push
在每次获取和推送时保持最新的“远程分支”之一。
“远程分支”,也称为“远程跟踪分支”,只是一个类似分支的标签,其“全名”以refs/remotes/
开头。名为origin
的远程数据库的所有内容都在refs/remotes/origin/
中。在正常操作中git fetch
咨询一些远程(如origin
)git存储库并询问:“嘿,你那边有什么分支,什么是SHA-1值?”获得答案后,它会将它们存储在您的 git存储库中:refs/remotes/origin/master
,refs/remotes/origin/devel
,等等。这样就可以让你知道“那边”的内容是什么,你的git最后一次有机会同步。
不应将这些与git称为“跟踪分支”(或“本地跟踪分支”)的内容混淆。本地分支是“全名”以refs/heads/
开头的标签。如果他们有与他们相关的“上游”信息,他们被认为是“跟踪”。您可以在首次创建分支时输入上游信息 - 这通常是具有与远程分支“相同”名称的本地分支的情况,例如master
vs origin/master
- 或者您可以稍后使用git branch --set-upstream-to
设置(或更改)。
所有这些与git pull
语法不同:git pull origin master
相当不同,而且年龄更大,完全超出了“远程跟踪分支”的整个概念。 1 这种偶然的相似之处,我认为是很多混乱的根源(我知道多年前我发现它很混乱)。
1 具体来说,您曾经(并且仍然可以)从URL而不是“远程”名称git pull
。这通常会(并且仍然)转移到另一个git存储库,并获得至少一些分支的列表(有时只是感兴趣的一个)。但是,因为它们是的分支,而不是你的分支,然后它们被记录在一个名为FETCH_HEAD
的文件中。所以此时,它会将master
从“那里”带过来,但是将其放入FETCH_HEAD
而不是远程跟踪分支 - 使用原始URL,您没有远程name,因此无法命名远程跟踪分支:没有origin
用于构造前缀refs/remotes/origin
。 master
的{{1}}参数则表示:“搜索git-pull
以找到他们的FETCH_HEAD
分支。”