使用 git 并希望从服务器获取更改时的约定是：
git fetch
git merge origin/master
我知道还有git pull，但我的具体问题是关于origin/master 的语法。 master 部分有什么作用？如果我只是做git merge origin（没有master），它似乎可以工作。我知道master 是一个分支，但是如果我要跟踪一个远程的多个分支，正常的用例是合并所有分支吗？
【问题讨论】：
标签： git merge branch git-merge branching-and-merging
merge 的参数被解析为提交 ID。这意味着应用了gitrevisions 中的规则。通常，origin/<em>name</em> 解析为 git fetch 和 git push 在每次 fetch-and-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 与 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，你没有远程名称，所以有无法命名远程跟踪分支：没有origin 可以用来构造前缀refs/remotes/origin。 master 到 git-pull 的参数意味着：“搜索 FETCH_HEAD 以找到他们的 master 分支。”
【讨论】：
当未指定分支时，git merge origin 将合并到从origin 远程（通常为master）设置为默认分支的任何分支中。在这种情况下，git merge origin 和 git merge origin/master 会做同样的事情。但是，如果您想合并到与 origin 不同的分支中，则必须指定分支。
【讨论】：
origin 最终匹配refs/remotes/origin/HEAD，如果存在的话。没有的地方（在这里的测试仓库中）：git merge origin 说 merge: origin - not something we can merge 但 git merge origin/master 合并（或者在这种情况下说 Already up-to-date.）。