"Philip Oakley" <philipoak...@iee.org> writes:
>> Allan Acheampong <allanad...@gmail.com> writes:
>>
>>> ... I'm new to git, but I found it very
>>> confusing to understand the difference between "remote" ,
>>> "remotes". Is it in the cloned repo, or is it in a remote place?
>>> If its local, why doesn't it get shown when I do 'git branch' but
>>> when I do 'git branch -a'.
>
> For the uninitiated, the lack of distinct terminology can cause no end
> of confusion as most explanations presume that you will implicitly
> understand the context, which can't be true for such newbies.
True.
* You work in a local repository.
* You interact with repositories other than the local repository.
Here, "to interact" mean "exchange the history with", either by
pushing the commits in the local repository to the other one(s),
or fetching the commits in the other one(s) to the local
repository.
These "other repositories" are "remote repositories" from the
point of view of the local repository.
Note that you may have two repositories you use for working on
the same project, one on your desktop and one on your notebook.
As far as the repository on your notebook is concerned, the
repository on your desktop, if you interact with it from the
repository on your notebook, is a "remote repository" (and the
one on the desktop views the one on the notebook as "remote").
* Often we call a "remote repository" just a "remote". Especially
when we give a convenience short-name to it, like "origin".
* When you "clone" from a repository to create a "copy" to work in,
from that new repository's point of view, the original repository
is a "remote repository", and "git clone" configures things in
the new repository so that you can conveniently interact with
that original repository. The last part is what lets you say
"git fetch origin", for example, to interact with the "origin"
remote.
* Branches are local to each repository. It is merely a social
convention that the primary branch in the repository you cloned
from (i.e. your "origin") is often called 'master', the primary
branch in the local repository is called 'master', and you often
interact with the history of the 'master' branch of the "origin"
when you are on your 'master' branch. There is no stronger tie
between their 'master' and your 'master' other than the social
convention, but Git makes it easier for you to work that way by
setting a few configuration variables.
* Some of the social conventions, and the configuration Git sets up
to let you follow them easily, allows you to find out where the
tips of branches at your remotes were, when you last observed
them (remember, Git is distributed, so you do not ask "right
now"; instead you have "when you last observed" and "make an
observation right now" separately). This is achieved by keeping
the record of the last observation in "remote-tracking branches".
The last observed value of the 'master' branch of the remote
repository "origin" is stored as 'origin/master' (its full name
is 'refs/remotes/origin/master', but you rarely have to spell it
out) remote-tracking branch.
CAVEAT: some older documentation call a "remote-tracking branch"
just "remote branch", but we have been trying to move away from
that practice, as it is confusing, because the 'master' branch at
the 'origin' remote is often called a 'remote branch'. When you
see 'remote branch', you need to make sure which one the writer
meant.
* "git fetch" (and "git pull", which internally invokes "git
fetch") is a way to "make the observation now". "git fetch
origin" updates your remote-tracking branches for the "origin".
* "git pull" (and "git pull --rebase") is a way to do the "fetch"
above and then integrate the history of the branch at the remote
(which now you know its latest state, because you just observed
it) with the history you have on your branch. Again, these
branches may be named 'master' but the user needs to be aware
that they are two separate branches (your 'master' branch is just
as a different entity from the 'master' branch of the remote
repository as it is your 'next' or any other branch).
To make it easier to work, git configures the history of which
branch you obtained/observed from what remote is to be integrated
with your history per your local branch. Immediately after "git
clone", you will typically have your 'master' branch, and the
branch "knows" that it wants to integrate with the 'master'
branch at 'origin' remote. So "git pull" becomes:
- "git fetch origin", because you will integrate with the
history that comes from that remote, not other remotes;
- which updates 'origin/master' remote-tracking branch, and
possibly other remote-tracking branches under 'origin/'; and
- integrate your branch with the history of 'origin/master'
remote-tracking branch.
We say "your 'master' branch is set to integrate with
remote-tracking branch 'origin/master'". It is morally
equivalent to say "your 'master' branch integrates with the
'master' branch of 'origin'".
CAVEAT: people often call this relationship between your 'master'
branch and 'origin/master' (or the 'master' branch of 'origin'
remote) "tracking", e.g. "your 'master' branch tracks
'origin/master'". Unfortunately, this is a confusing misnomer, as
the relationship between the 'master' branch of 'origin' and the
remote-tracking branch 'orign/master' you have in your local
repository is also called "tracking" (the latter keeps track of
the former). You are better off avoid using the word "track" for
this purose, unless it is very clear from the context.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
