Reputation: 7468
From git-scm book:
Let’s say you have a Git server on your network at git.ourcompany.com. If you clone from this, Git’s clone command automatically names it origin for you, pulls down all its data, creates a pointer to where its master branch is, and names it origin/master locally. Git also gives you your own local master branch starting at the same place as origin’s master branch, so you have something to work from.
Would this hold true even if in remote we have several branches apart from 'master'. As 'master' is not a special branch, it is just default name of the first branch when we do 'git init'.
So why would cloning remote repository create pointer to position of only 'master' branch?
Upvotes: 1
Views: 161
Reputation: 487883
Would this hold true even if in remote we have several branches apart from 'master'.
Generally, yes.
As 'master' is not a special branch, it is just default name of the first branch when we do 'git init'.
That's also correct.
So why would cloning remote repository create pointer to position of only 'master' branch?
git clone url directory
is a convenient shorthand for the following steps:
mkdir directory
(and then all subsequent steps happen inside directory
, although your own command-shell remains outside it so that you have to cd directory
afterward);git init
;git config
s necessary based on additional clone options (e.g., --bare
or --mirror
set core.bare
; there are many possibilities here);git remote add origin url
(or some other name than origin
if you have set the -o
option);git fetch
;git checkout master
(or git checkout
some other name if you have set the -b
option, or in one other case).It's this final git checkout
step that creates your local master
branch. Note that this does not depend on the number of branches in the remote. It does, however, depend on the remote having a master
branch.
When you ask git checkout
to check out a branch that does not exist yet in your own repository, instead of immediately failing with an error message saying "you don't have that branch", Git looks at all of your remote-tracking names, such as origin/develop
and origin/master
. In the six-step process above, those names were created by git fetch
, which copied all of the branch names in the other Git at url
. Thus, if they have the two branches develop
and master
, your clone now has the two remote-tracking names origin/develop
and origin/master
.
Git scans through those remote-tracking names. One of them resembles master
. Git, in effect, says to itself: Aha, you did not just mean "check out existing master
", you meant "create new master
based on origin/master
", then check out master
.
That's why cloning the remote repository creates only master
: you only asked it to git checkout master
.
Now, I mentioned above the -b
option, plus one other case. If you run git clone -b develop url directory*
, you tell your Git to run git checkout develop
at the end instead. So you will create your own develop
based on origin/develop
.
If you don't use -b
, your own Git asks their Git: Which branch do you recommend checking out? The default answer is master
, which is why you usually end up with git checkout master
. But their Git can supply a different name. Web services like GitHub and Bitbucket offer web interfaces to set this. If you're running a corporate server, it's up to you to set it yourself (the trick is to set the symbolic HEAD
name in the server-side bare repository). If you are just using someone else's setup, don't worry about it: you cannot control their Git, but you do have your -b
option when you run git clone
.
Upvotes: 1