使用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分支。”