current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
up vote 100 down vote favorite
39

I think I'm on the right track to understand the basic concepts of git.

I've already set up and cloned a remote repository. I also created a server side empty repository, and linked my local repository to it.

My problem is that I don't understand the difference between:

  • origin/master vs. remotes/origin/master

As far as I have understood, master is a local branch, and remotes/origin/master is a remote one.

But what exactly is origin/master?

share|improve this question
    
@ChristopherWallace: You provoked two questions on meta with your edit: "Do we really need an [origin] tag?" and "What is the true [Master]?". – Deduplicator Jul 1 '15 at 17:19
    
@Deduplicator Is that a problem? – Nunca me esqueci de ti Jul 1 '15 at 18:52
    
@ChristopherWallace: Well, many seem to think both tags (the one you created and the one you just added) are bad. I happen to concurr, but perhaps you have something to add to the discussion linked which wasn't considered. If not, seems so. – Deduplicator Jul 2 '15 at 12:52
up vote 121 down vote accepted

Take a clone of a remote repository and run git branch -a (to show all the branches git knows about). It will probably look something like this:

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Here, master is a branch in the local repository. remotes/origin/master is a branch named master on the remote named origin. You can refer to this as either origin/master, as in:

git diff origin/master..master

You can also refer to it as remotes/origin/master:

git diff remotes/origin/master..master

These are just two different ways of referring to the same thing (incidentally, both of these commands mean "show me the changes between the remote master branch and my master branch).

remotes/origin/HEAD is the default branch for the remote named origin. This lets you simply say origin instead of origin/master.

share|improve this answer
3  
Good answer. I think git branch -a showing the remote branch as remotes/origin/master is partly because the underlying ref is stored in .git/refs/remotes/origin (if it hasn't been packed). In my opinion, the output of git branch -a could be much clearer, perhaps by separating the name of the remote from the name of the branch with something other than a slash. – Matt Hurne May 14 '12 at 18:13
5  
Also note that git branch -r, which is to show remote branches only, will show the branch as just origin/master because the remotes/ prefix isn't necessary. – Matt Hurne May 14 '12 at 19:26
3  
@misterbiscuit: thats true. The output is more confusing than clarifying. Thanks a lot, a great answer to my quesion that gave me the right hints – John Rumpel May 17 '12 at 11:44
up vote 51 down vote

Short answer for dummies like me (stolen from Torek):

  • origin/master is "where master was over there last time I checked"
  • master is "where master is over here based on what I have been doing"
share|improve this answer
7  
This is the simplest and perfect answer for dummies like me – Zoran P. May 17 '15 at 14:47
1  
origin/master = backup of remote machine, updated last time you checked master = your copy of origin/master – sakurashinken Mar 17 at 0:27
up vote 26 down vote

Technically there aren't actually any "remote" things at all in your git repo, there are just local names that should correspond to the names on another, different repo. The ones named origin/whatever will initially match up with those on the repo you cloned-from:

git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...

makes a local copy of the other repo. Along the way it notes all the branches that were there, and the commits those refer-to, and sticks those into your local repo under the directory .git/refs/remotes/origin/.

Depending on how long you go before you git fetch or equivalent to update "my copy of what's some.where.out.there", they may change their branches around, create new ones, and delete some. When you do your git fetch (or git pull which is really fetch plus merge), your repo will make copies of their new work and change all the refs/remotes/origin/<name> entries as needed. It's that moment of fetching that makes everything match up (well, that, and the initial clone, and some cases of pushing too—basically whenever git gets a chance to check—but see caveat below).

Git normally has you refer to your own refs/heads/<name> as just <name>, and the remote ones as origin/<name>, and it all just works because it's obvious which one is which. It's sometimes possible to create your own branch names that make it not obvious, but don't worry about that until it happens. :-) Just give git the shortest name that makes it obvious, and it will go from there: origin/master is "where master was over there last time I checked", and master is "where master is over here based on what I have been doing". Run git fetch to update git on "where master is over there" as needed.

Caveat: in versions of git older than 1.8.4, git fetch has some modes that don't update "where master is over there" (more precisely, modes that don't update any remote branches). Running git fetch origin, or git fetch --all, or even just git fetch, does update. Running git fetch origin master doesn't. Unfortunately, this "doesn't update" mode is triggered by ordinary git pull. (This is mainly just a minor annoyance and is fixed in git 1.8.4 and later.)

share|improve this answer
    
Thanks a lot torek. You and larsks gave great answers and of course ... you lifted this fog – John Rumpel May 17 '12 at 11:45
1  
Thanks Torek - i've stolen a bit of your answer for a dummies version - hope you don't mind – ErichBSchulz Feb 17 '13 at 5:48
up vote 2 down vote

One clarification (and a point that confused me):

"remotes/origin/HEAD is the default branch" is not really correct.

remotes/origin/master was the default branch in the remote repository (last time you checked). HEAD is not a branch, it just points to a branch.

Think of HEAD as your working area. When you think of it this way then 'git checkout branchname' makes sense with respect to changing your working area files to be that of a particular branch. You "checkout" branch files into your working area. HEAD for all practical purposes is what is visible to you in your working area.

share|improve this answer
    
More precisely, HEAD is a "pointer to a branch" (the actual file in your local repo often contains the string ref: refs/heads/master, for instance ... unless it's "detached", which is another thing entirely). However, there's a bug of sorts in the way clone interprets the "remote HEAD": the transfer protocols can't send an indirect branch at all, just a raw SHA-1, so git has a kludge that makes this "mostly work". Every once in a while someone stumbles across a weird case though. I kind of wish git did not create remotes/origin/HEAD at all, especially when it comes out wrong... – torek Oct 3 '13 at 9:14

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.