Difference between remotes/origin and origin

Question

I am working on a new repository on GitLab, however when I list the branches it shows: remotes/origin/branch1. The times I worked with git it would show only: origin/branch1. If I create a branch like: git checkout -b myBranch would it show like: remotes/origin/myBranch or do I have to make some kind of config before. Sorry if it's a stupid question, I am new in this.

Answer 1

@torek has explained deeply on this. Credits to him.

If you write a command git checkout -b mybranch then it will create a new branch named mybranch in your local and it will switch to that new branch from the default branch so that you can work on that branch. Tip: The default branch is master or main branch depending upon version control application you are working on.

Now if you do git branch. It will show your local branches that comes from ref/heads reference like master and *mybranch. * indicates that your Head is pointed to that branch.

$ git branch
  *mybranch
  master

If you do git branch -r. It will show remote branches from ref/remotes.

$ git branch -r
  origin/master

For displaying the list of both local and remote branches which comes from ref/heads and ref/ reference, you need to use git branch -a.

$ git branch -a
  *mybranch
  master
  remote/origin/master

If you want to push the newly created branch into the remote repo.

git push origin mybranch

If you working alone then you need to first check out to master branch then merge it with the newly created branch to the master branch by

git checkout master
git merge mybranch

If you are working in a team then you need to do the pull request so that everyone in your team knows that you have pushed your new branch and requires the approval of the team member to merge the branch to the master branch.

Answer 2

This guy is Harcourt Fenton Mudd. Is he also Harry Mudd?

(Hint: Yes. Yes he is. Well, modulo whether you're into Star Trek, anyway. Okay, that wasn't a hint.)

origin/branch1 [vs] remotes/origin/branch1

Both of these are actually abbreviations: the full spelling of this name is refs/remotes/origin/branch1. Git lops off the refs/remotes/ part, except when—for no apparent reason¹—it only lops off the refs/ part.

The full name begins with refs/. According to the gitglossary, that makes it a ref or reference. This is a generalization of branch names, tag names, and other such names, so that one piece of code inside Git—the reference handling code—can deal with all the different kinds of refs. It also means that if someone hands you a full reference, you can tell what kind it is:

• refs/heads/name is the branch name name;
• refs/tags/name is the tag name name; and
• refs/remotes/remote/name is a two-part remote-tracking name.²

Confusingly, these two part names are made up of:

• a remote name, which is not a remote-tracking name; plus
• your Git's copy of some other Git's branch name, as of the last time that your Git saw their Git's branch name (and corresponding commit hash ID).

The remote in this case is origin. A remote is a short name under which your Git can store some facts. The primary fact stored under a remote is a URL: your Git will use this URL to contact the other Git, when you run git fetch or git push.³

What this all boils down to is that when you see refs/remotes/origin/branch1, that tells you that:

• your Git has, or had, a remote named origin;
• at some point, your Git called up some other Git using that name;
• at that point, their Git had a branch name, refs/heads/branch1, or branch1 for short; and
• your Git copied that branch name into your own repository, renaming it to origin/branch1 (for short) to keep it away from your branch names. Your branch names are yours. They are not to be messed with just because some other Git has some branch names! The other guy using that other Git can mess with his branch names all he wants; your Git won't mess with yours just because he messed with his.

If you want to create your own branch name branch1 (full name refs/heads/branch1), you're free to do that. If you'd like it to associate, in some way, with their branch1 (your origin/branch1), you can do that too, by setting your origin/branch1 as the upstream of your branch1.

---

¹The command-line command that is squirrelly here is git branch: git branch lists (local) branch names and lops off refs/heads/ from each, and git branch -r lists remote-tracking names and lops off refs/remotes/ from each; but git branch -a lists both, lopping off refs/heads/ from the branch names while lopping off only refs/ from the remote-tracking names. I have never seen anything that says why it does this. There are probably hysterical raisins involved.

²Git documentation calls these remote-tracking branch names, but they don't act like branch names, and I find the word branch in this phrase just muddies the waters. Calling them remote-tracking names is not much of an improvement, but it seems better.

³You can store more than one URL, if for some reason you want to git fetch from one URL and git push to a different one. You can also store some configuration items under the remote name. The command that manipulates remote names and their stored URLs and other data is git remote.

---

Summary

You've learned these technical terms:

• remote: a short name for a URL. There are relatively few restrictions on these names, and they don't have a long spelling and a short one.
• branch name: a name (that keeps track of a commit ID—we didn't go into this much detail) that your own Git maintains for you, once you have your Git create it. A branch name has a fully spelled out long form, which you can use when it's in trouble,⁴ the way "Harry Mudd" becomes "Harcourt Fenton Mudd" when Stella Mudd is angry with him.
• remote-tracking name: a name (that keeps track of a commit ID) that your Git copies, rather slavishly, from some other Git, but changes it around during the copying, so that it won't ever conflict with any of your branch names.
• upstream: a way to link a branch name to some other name—usually a remote-tracking name, but you can use a branch name here too—to make some things more convenient. (We haven't gone into detail about what this makes convenient.)

---

⁴You might wonder when a branch name could possibly be in trouble. The answer is: when it's also a tag name, or some other name. What if you accidentally make v1 as both a tag and a branch? There are some rules that Git uses, but they're pretty weird: the tag name often wins, but not always, and it gets confusing. But you can just write out the full name—refs/heads/v1 or refs/tags/v1—to get around that, or use an abbreviated name, but one less abbreviated: heads/v1 or tags/v1.

(The git describe command sometimes prints out heads/name, to warn you that it's a branch name instead of a tag name.)