是什么决定了"git clone"之后的默认分支?

Chr*_*tze 37 git git-clone

我的理解是克隆存储库的默认分支是HEAD指向克隆的repo中的任何内容.

我现在有一个案例,这不是真的.我的理解显然是有缺陷的,那么在克隆(裸)repo时,什么决定了默认的checkout分支呢?

该repo的最后一次提交是在裸仓库的HEAD中引用的分支与我在克隆中作为checkout分支获得的分支之间的合并.

运行git remote show origin回报:

Fetch URL: ...
Push  URL: ...
HEAD branch (remote HEAD is ambiguous, may be one of the following):
  <bad-branch>
  live
Remote branches:
  ...
Run Code Online (Sandbox Code Playgroud)

Bare repo使用Git版本1.8.2.1,客户端使用1.7.12.4,传输是SSH.

也许答案实际上是这里的答案.这个答案证实了这一点.如果选择的符号引用都指向与HEAD相同的修订版,则客户端将猜测要使用哪个分支.

Edw*_*son 26

Git 1.8.5开始,服务器将HEAD在"symref"功能中发送指向的实际分支名称.如果你的客户端和服务器都比Git 1.8.5更新,它将HEAD 正确更新.

在此之前,客户端将通过比较HEAD(最终)指向的对象ID与所有分支的所有对象ID来猜测HEAD可能指向的内容.它喜欢一个名为分支refs/heads/master:如果两个HEADmaster指向同一个对象ID,然后克隆将设置默认分支在新的存储库master.

否则,具有匹配OID的第一个分支(当分支按字母数字顺序排序时)将是默认分支.如果没有分支具有匹配的OID,则将HEAD直接设置为对象ID(即,分离的HEAD).

  • 实际上,HEAD不是指向提交的指针。它是指向_branch_的指针。那就是确定“当前已检出分支”实际上是什么的原因。因此,要确定最后一次提交,首先要查看“ HEAD”,它指向(例如)“ master”,而_master_实际上是指向一个提交。 (2认同)
  • (请注意,从技术上讲,我应该说`HEAD`不是_通常指向提交的指针。如果您进入“分离的HEAD状态”,即直接检出一个提交而不是一个分支,则` HEAD`实际上会指向一次提交。) (2认同)

Val*_*ntz 13

这实际上是HEAD指出的.使用git symbolic-ref HEAD refs/heads/mybranch设置HEAD.(来源:http://feeding.cloud.geek.nz/posts/setting-default-git-branch-in-bare/)


Car*_*rum 7

一个裸露的回购也有一个HEAD.这就是克隆它时得到的结果.

git clone文档:

将存储库克隆到新创建的目录中,为克隆存储库中的每个分支创建远程跟踪分支(可见使用git branch -r),并创建并检出从克隆存储库的当前活动分支分叉的初始分支.

关于"当前活动分支"的位是指远程的HEAD修订版.

如果您想要不同的行为,可以使用--branch-b:

--branch <name>
-b <name>
而不是将新创建的指向指向HEAD克隆存储库所HEAD指向的<name>分支,而是指向分支.在非裸存储库中,这是将要检出的分支.--branch也可以HEAD在生成的存储库中获取标记并分离该提交.

  • 我的问题是,它似乎不是真的.在远程裸仓库上,HEAD包含"ref:refs/heads/live".当我克隆时,我会指向另一个分支.现在,事实证明,该分支上的最后一次提交是从"远程跟踪分支'origin/live'"合并到分​​支中.有点奇怪. (3认同)