为什么我需要git merge origin / master中的“master”？

Question

使用git并希望从服务器获取更改时的约定是：

git fetch

git merge origin/master

我知道还有git pull ，但我的具体问题是关于语法origin/master 。 master部分做什么？ 如果我只是做git merge origin （没有master ）它似乎工作。 我知道master是一个分支，但是如果我跟踪一个以上的远程分支，那么正常的用例是否会合并所有这些分支？

Answer 1

当未指定分支时， git merge origin将合并在从origin远程（通常为master ）设置为默认的任何分支中。 在这种情况下， git merge origin和git merge origin/master将做同样的事情。 但是，如果要在origin的不同分支中合并，则必须指定分支。

Answer 2

要merge的参数merge解析为commit-ID。 这意味着应用了gitrevisions中的规则。 通常， origin/ name解析为git fetch和git push之一的“远程分支”在每次获取和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是相当不同的，并且更古老，完全超越了“远程跟踪分支”的整个想法。 ¹这种偶然的相似之处，我认为是很多混乱的根源（我知道多年前我发现它很混乱）。

---

¹具体来说，您曾经（并且仍然可以）从URL而不是“远程”名称进行git pull 。 这通常会（并且仍然）转移到另一个git存储库，并获得至少一些分支的列表（有时只是感兴趣的一个）。 但是，因为它们是它的分支而不是你的分支，所以它们被记录在名为FETCH_HEAD的文件中。 所以在这一点上，它会从“那里”带来master ，但把它放到FETCH_HEAD而不是远程跟踪分支 - 用原始URL，你没有远程名称，所以没有办法命名远程跟踪分支：有没有origin与构建前缀refs/remotes/origin 。 然后git-pull的master参数意味着：“通过FETCH_HEAD搜索以找到它们的master分支。”