Mandroid
Mandroid

Reputation: 7468

A query on 'git clone'

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

Answers (1)

torek
torek

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:

  1. 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);
  2. git init;
  3. run any git configs necessary based on additional clone options (e.g., --bare or --mirror set core.bare; there are many possibilities here);
  4. git remote add origin url (or some other name than origin if you have set the -o option);
  5. git fetch;
  6. and finally, 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

Related Questions