11

I know this can be done on the Admin page of a repository. Another default branch can be set there. And that would be the answer of this question.

But I discovered (maybe a bug?) the following. If your master branch and develop branch are exactly the same, than a git clone will not clone the default "develop" branch, but still "master"!! If you commit something to the develop branch, remove your clone and than clone again, you will get the develop branch!

Is this Git behaviour or Github? And can this be fixed to set it ALWAYS to develop?

Pieter Vogelaar
  • 365
  • 2
  • 4
  • 16
  • Odd - I can reproduce this too. I'd report it to GitHub as a bug... – Mark Longair Oct 06 '12 at 12:18
  • 1
    @MarkLongair not odd: this is how git is supposed to work. See my answer below. – VonC Oct 06 '12 at 22:42
  • @VonC: OK, so it's a git bug then, or at least a misfeature. HEAD is a symbolic ref, but for some reason it throws away that indirection when cloning, and just looks up a branch that points to the object name? That doesn't make any sense to me, and creates surprises such as that the questioner has found. – Mark Longair Oct 07 '12 at 12:30
  • @MarkLongair `HEAD` seems to reference here a commit, not a branch. If that commit happens to be referenced by `master`, then `master` is considered the default branch. If that is true, then it is not a bug, it is a "feature", or, in this case, a convention. – VonC Oct 07 '12 at 18:39

1 Answers1

10

This is a git "feature"

I just tested it with local repo, and while the HEAD of my first repo test is "develop":

C:\Users\VonC\Documents\GitHub\test>git symbolic-ref HEAD
refs/heads/develop

... the name of the default branch cloned in test1 is master!

C:\Users\VonC\Documents\GitHub\test1>git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master

See "How do I change a Git remote HEAD to point to something besides “master":
From the cloned repo perspective, HEAD on the remote origin repo references both master and develop:

C:\Users\VonC\Documents\GitHub\test1>git ls-remote origin
c215dd28ea8bf9b0c6b522c784b70bbbb3e858a5        HEAD
c215dd28ea8bf9b0c6b522c784b70bbbb3e858a5        refs/heads/develop
c215dd28ea8bf9b0c6b522c784b70bbbb3e858a5        refs/heads/master

And the order for determining the default branch of a cloned repo is:

  • HEAD references refs/heads/master and that exists -> you get a local branch called master, starting from origin/master
  • HEAD references refs/heads/anotherBranch and that exists -> you get a local branch called anotherBranch, starting from origin/anotherBranch
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • See this answer: http://stackoverflow.com/a/22109385/1421847 "git remote set-head origin develop" worked fine. All new pull requests are now targeting develop branch instead of master. – Eivind Gussiås Løkseth Dec 21 '16 at 10:24
  • 1
    @EivindGussiåsLøkseth as mentioned in the comments of the answer you reference, isn't that only valid for your local repo though? The repo on GitHub side would not be aware of a `git remote set-head` directive. – VonC Dec 21 '16 at 10:31
  • Maybe you're right. The first PR that I made after running this command automatically targeted develop for some reason, but now a new PR targets master again. Not sure why it seemed to work in the first place. – Eivind Gussiås Løkseth Dec 21 '16 at 13:33
  • 1
    @EivindGussiåsLøkseth git clone/fetch/pull/push and ls-remote are the only commands communicating with a remote repo. Everything else is purely local to your repo. – VonC Dec 21 '16 at 13:37