There are two official definitions, and both definitions are widely used on the internet. It's confusing, but unfortunately, I don't see a way to fix this problem, so I have left both defined here.
The first definition comes from Chapter 3.5 in Pro Git. Here is the exact quote:
Remote references are references (pointers) in your remote repositories, including branches, tags, and so on. You can get a full list of remote references explicitly withgit ls-remote <remote>, orgit remote show <remote>for remote branches as well as more information. Nevertheless, a more common way is to take advantage of remote-tracking branches.
It's pretty clear from this paragraph that Pro Git is talking about references that exist only on external repository.
Although Chapter 3.5 uses the term "remote repository", they mean external repository. We know this because git ls-remote can be utilized either with the shortname like in the examples in the chapter (git ls-remote <shortname>) or with a a full URL to a repository that has no remote name in our local repository (git ls-remote <URL>).
The second definition comes from Chapter 10.3 in Pro Git.
The chapter attempts to describe the different types of Git references. The chapter does not do a good job of describing references (thankfully, my glossary entry covers the term fully), but it does do a good job of describing how references are stored. There are three parts to the chapter:
What's important to note is that all three parts explain how the information is stored locally.
My glossary entries cover the complexities of HEAD, tags, and everything else (thus fixing the ommissions of chapter 10.3), so I won't go over that here. Instead, I wish to focus on the section with "remotes".
The "remotes" section describes very plainly that the information is stored locally in .git/refs/remotes/....
Here is the exact quote I wish to focus on:
The third type of reference that you’ll see is a remote reference. If you add a remote and push to it, Git stores the value you last pushed to that remote for each branch in therefs/remotesdirectory... Remote references differ from branches (refs/headsreferences) mainly in that they’re considered read-only.
In other words, this chapter defines a "remote reference" as a reference found in a remote repository, but the information about the remote reference is stored in the local repository.
As with many things from the official documentation, I am suspicious about how many errors are here. For instance, I know that references in any form are not read-only. (You should treat it as read only, but it is not read-only.) Additionally, the difference between a reference and a branch is that a reference points to a Git object while a branch points to a commit object. (A commit object is one of the four types of Git objects.)
Nevertheless, this chapter uses several paragraphs to describe how a remote reference is stored locally and since many people seem to utilize this definition, I think it's fair to call the second entry a valid definition.
Per Git documentation, if a reference on a local repository points to a reference on an external repository, it's possible that the reference is both simultaneously a local reference and a "remote reference". See the detailed definition of local reference for more information.
I promised not to use the simple term "remote" anywhere in my notes because it's confusing. Unfortunately, I use the term "remote" a little bit to explain the second definition because I'm directly quoting Pro Git, Chapter 10.3, the section on Remotes. This short section relies heavily on the incorrect use of the term remote. If you're wondering which definition of remote is used, then wonder no more: four of the five are used. Sometimes they are used within the same sentence. I will rewrite part of the text using my terminology:
The third type of reference that you’ll see is a remote reference. If you add a remote name and push to the remote repository, Git stores the value you last pushed to that remote repository for each branch in the
refs/remotesdirectory. For instance, you can add a shortname calledoriginand push your master branch to it...Then, you can see what the
masterbranch on theoriginrepository was the last time you communicated with the server, by checking therefs/remotes/origin/masterfile...
It's difficult to get an exact official definition for "remote reference" because the term is actually hardly used in official documentation. (No, really. Outside of Chapter 3.5 and Chapter 10.3, Pro Git doesn't use it very often. Feel free to search through the pdf version that contains all chapters if you don't believe me.)
The term is not to be found in the Official Git glossary, but it is alluded to in the term Official glossary entry for refspec. Incorrectly, the term "refspec" distinguishes between "ref" and "local ref" implying that "ref" stands for "remote reference". This is incorrect, however. Ref is actually short for reference, and if you read the Git glossary definition of ref, you'll see that the official glossary for "ref" is describing a "reference" and not a "remote reference".
And as far as I can tell, the term "remote reference" is hardly used in the man pages, if at all, but I didn't do a thorough check.
I've seen more than one unofficial website say git remote adds and removes "remote references". As explained in my glossary definition of remote and in Demystifying Remotes, it does not.
I don't know what happened in the development of the Git terminology which allowed two very different and opposite official definitions for "remote reference" to exist, but it's not hard to imagine:
.git/refs. Specifically, references that are about remote repositories (i.e., remote-tracking branches) are stored in .git/refs/remotes. Therefore, a remote-tracking branch is a "remote reference".In any case, the situation is unfortunate. I don't see a way to fix this except to take one of the definitions and assign it a new term, but I'm far from convinced that this is a good idea. I think a discussion to resolve this problem is warranted.