Why do I need the “master” in git merge origin/master?

Question

The convention when using git and you want to get changes from the server is:

git fetch

git merge origin/master

I know there is also git pull , but my specific question is about the syntax origin/master . What does the master part do? If I just do git merge origin (without the master ) it seems to work. I know master is a branch, but if I'm tracking more than one branch of a remote, would the normal use case be to merge all of them?

Answer 1

When a branch is not specified, git merge origin will merge in whatever branch is set as default from the origin remote (generally master ). In such cases, git merge origin and git merge origin/master will do the same thing. If you wanted to merge in a different branch from origin , though, you'd have to specify the branch.

Answer 2

The argument(s) to merge are resolved to commit-IDs. This means that the rules in gitrevisions are applied. In general, origin/ name resolves to one of the "remote branchs" that git fetch and git push keep up-to-date on every fetch-and-push.

A "remote branch", also called a "remote-tracking branch", is simply a branch-like label whose "full name" starts with refs/remotes/ . All the ones for the remote named origin are in refs/remotes/origin/ . In normal operation git fetch consults some remote (like origin ) git repository and asks it: "hey, what branches do you have over there, and what are their SHA-1 values?" When it gets the answers, it stores them locally, in your git repository: refs/remotes/origin/master , refs/remotes/origin/devel , and so on. So that lets you know what things looked like "over there", the last time your git had a chance to sync up.

These should not be confused with what git calls "tracking branches" (or "local tracking branches"). Local branches are labels whose "full name" starts with refs/heads/ . They're considered "tracking" if they have "upstream" information associated with them. You can have the upstream information put in when you first create the branch—this is typically the case for local branches with the "same" names as remote-branches, like master vs origin/master —or you can set (or change) it later with git branch --set-upstream-to .

All of these are different from the git pull syntax: git pull origin master is rather different, and much older, predating the whole idea of "remote-tracking branches" entirely. ¹ This sort of accidental resemblance, as it were, I think is the source of a whole lot of confusion (I know I found it confusing, years ago).

---

¹ Specifically, you used to (and still can) git pull from a URL rather than a "remote" name. That went (and still goes) over to the other git repository as usual, and gets a list of at least some of its branches (sometimes just the one of interest). But, because those are its branches, not yours, they are then recorded in a file called FETCH_HEAD . So at this point, it will have brought master over from "over there", but put it into FETCH_HEAD rather than a remote-tracking branch—with a raw URL, you don't have a remote name, so there's no way to name the remote-tracking branch: there's no origin with which to construct the prefix refs/remotes/origin . The master argument to git-pull then means: "go search through FETCH_HEAD to find their master branch."