Reputation: 2632
So I'm a tad confused on git fetch
'ing. When I fetched on a remote, it said that there were 5 new branches:
From https://github.com/***************
* [new branch] ca***** -> **********
* [new branch] ma***** -> **********
...
* [new tag] v*** -> v***
Yet if I do a git branch
on my local system, they're not there. Obviously I'm not understanding git fetch
, and reading the man pages didn't help my grasp of what little I know of git. Can someone give me a short explanation of the fetch?
Upvotes: 0
Views: 80
Reputation: 2066
You should do git checkout --track origin/<branch_name>
then do a git fetch origin
Upvotes: 0
Reputation: 489758
With git fetch
you have "remotes". The usual first remote is origin
but there might be more.
With git in general, people have branches.
A remote repository is usually a git repository, which means ... it has branches.
Let's say you decided to create a new branch that nobody else is using, for your own use. You cleverly call it branch
. Alas, now Joe has the exact same idea and called his branch branch
, and he pushes it to the repository you are both sharing over at origin
.
Then you run git fetch origin
(or git fetch
such that it reaches over to origin
, same thing). And... it brings over Joe's branch
.
What happens to your branch?
The answer is: nothing! That's the great thing about git branches: your local branches are yours, and yours alone, and only you can affect them.
But what if you want to use "their" branch? Well, when your git consults theirs and gets a list of "their" branches, it renames them. If you are picking up branches from origin
, and over there, there's one named branch
, git changes your copy to a "remote branch", which it names origin/branch
. If you have more remotes, the branch branch
on remote another
becomes another/branch
.
So, origin/cawhatever
is "your copy" of "branch cawhatever
", as last seen on the remote named origin
, the last time your git had a chance to go over there and see what was there. Git updates these on both fetch
and push
operations (although in older versions of git, if you run it the way git pull
does, it suppresses the updates of the "remote branches").
The full story is a bit longer: your local branches have a "full name" that starts with refs/heads/
. This is basically a "directory" or "folder" full of branch names (and/or subdirectories with more branch names). Remote branches live in a space underneath the "directory" refs/remotes/
. That guarantees that yours and theirs never collide. But sometimes when you add a remote, it might accidentally have the same name as a branch you've made. (Think about what happens if you create a local branch named origin
, for instance!) In this case you have to spell out the longer form of the name (see gitrevisions).
Tags live under refs/tags/
. There is no tag renaming built in, so when you bring over their tags, they go into the same name-space as your own tags. This makes using tags a bit more delicate, especially if you start talking to a number of different remotes.
For the most part, though, just think of remote branches as "what they had last time I checked". You can have your (local) branches "track" remote branches, and then git status
will tell you how far "ahead" and/or "behind" you are, from what's in your repository in the copy of "what they had last time I checked".
Upvotes: 1