没有主分支的Git仓库 [英] Git repository created without a master branch

问题描述

我想为一个新项目（在虚拟机上）创建一个新的共享git仓库。

我运行了 git --bare init 来自 /.../ git / new_proj.git ，但是没有在中创建主分支... /git/new_proj.git/refs/heads 目录。
我也在我的目录中运行了 sudo chmod 777 -R ，但它没有帮助，并且在之后仍然没有创建主设备。 init 命令。

编辑：
我甚至尝试使用 git init （没有裸标志），但仍然没有创建主分支。

Google在这件事上帮助不大。 。

任何人都知道问题是什么？我失踪的东西？感谢！ 解决方案

它已经在至此为止的其他答案，但这是非常正常的：一个新的存储库，裸或没有，没有提交，所以它也没有任何引用。

它有一个 HEAD ，它是一个名为 HEAD 的文件库（ .git 目录），其中包含符号分支名称引用。如果你 cat HEAD ，你会看到 ref：refs / heads / master ，这意味着新的仓库on分支主人，即使分支主人不存在 。再次，这是一个完全正常的事态。在这一点上，你被认为是未出生的分支。

当您向此空存储库添加一个或多个提交时， master 分支可以 - 如果它是一个裸回购，您可能会通过 git push 添加它，这可能不会提供 master 分支，所以我们不要说does:-)，尽管通常 master 确实存在于那个点上，引用指向新的提交（或提交链的新提示）。

在任何回购（无论是否还是），您都可以在分支上那不存在。特别是在一个普通的仓库中，您可以这样做：

  $ git checkout --orphan newbranch 
  
 
 
可以让你开 newbranch （通过编写 ref：refs / heads / newbranch 转换为 HEAD ）而不是实际创建  newbranch 然而，使得 newbranch 一个未出生的分支。接下来的提交会导致 newbranch 出现，并且该提交没有父提交（因此  -  orphan 部分）：它是一个新的根提交。这与 第一次提交时 master 存在的方式相同。
 
 
 
如果你可以用下面的机制来看它：当git创建一个新的提交时，用于更新 HEAD 的步骤如下所示： 1  
 $ b 
 
 
阅读 HEAD 文件的内容。
 
 
它是符号引用，例如 ref：refs / heads / master ？ 
 
否（detached HEADcase）：通过提交ID在 HEAD 并将新的SHA-1写入 HEAD 中。停止，我们完成了。
 
 
读取引用分支的SHA-1（例如， .git / refs / heads / master 如果没有SHA-1可用，因为分支尚不存在，则创建根提交，否则创建提交，其父代是给定的SHA-1。写新的SHA-1到引用分支。停下来，我们完成了。
 
 
作为一个有趣的侧面说明，当裁判打包时，积极的裁判（例如，重新开发，例如 devel ）结束于 .git / packed-refs ，但是很快更新具有新的价值。这些新值仅在 .git / refs / heads / devel 文件中 ： .git / packed-refs 文件保留一个 refs / heads / devel 条目，但是它是陈旧的（因此被忽略）。 （你不应该依赖这个：外部程序，比如shell脚本，应该使用 git branch 或者 git update-ref 或 git symbolic-ref 来读取和写入ref-name和SHA-1的值，但偶尔能够进入并且直接编辑引用，可以把它当作一个相当于磁盘扇区的十六进制编辑器的现代版本:-)）
 
 
 
 
 
 
  1 这一切都假定您没有创建合并提交。如果 在合并过程中，则存储库中的另一个文件（ .git / MERGE_HEAD ）会提供额外的合并父ID。 p> 
I want to create a new shared git repository for a new project (on a VM).


I ran git --bare init from /.../git/new_proj.git, but a master branch is not created in the .../git/new_proj.git/refs/heads directory.
I also ran sudo chmod 777 -R on my directory, but it didn't help, and still no master is created after the init command.

Edit:
I even tried to use git init (without the bare flag), but still the master branch was not created.

Google wasn't much help in this matter...

Anyone know what the problem is? Something I'm missing? Thanks!
解决方案
It's already in the comments on the other answer so far, but this is perfectly normal: a new repository, "bare" or not, has no commits, so it has no references either.

It does have a HEAD, which is a file named HEAD in the repository (the .git directory), containing a symbolic branch name reference.  If you cat HEAD you'll see ref: refs/heads/master, meaning that the new repository is "on branch master", even though branch master does not yet exist.  Again, this is a perfectly normal state of affairs.  You're said to be "on an unborn branch", at this point.

When you add one or more commits to this empty repository, the master branch can—if it's a bare repo, you may be adding this via git push which may not provide a master branch, so let's not say "does" :-) although usually master does—come into existence at that point, with the reference pointing to the new commit (or the new tip commit of a chain of commits).

In any repo (bare or not, again), you can be "on" a branch that does not exist.  In particular, in an ordinary repo, you can do:
$ git checkout --orphan newbranch
which puts you "on" newbranch (by writing ref: refs/heads/newbranch into HEAD) without actually creating newbranch yet, making newbranch an "unborn branch".  The next commit then causes newbranch to come into existence, and that commit has no parent commits (hence the --orphan part): it is a new root commit.  This is the same way master comes into existence on its first commit.

If you like, you can look at it in terms of underlying mechanism: when git creates a new commit, the steps used to update HEAD go like this:1

Read contents of HEAD file.
Is it a symbolic ref such as ref: refs/heads/master? if yes, go to step 4.
No ("detached HEAD" case): create commit with parent given by commit ID in HEAD and write new SHA-1 into HEAD.  Stop, we are done.
Read SHA-1 of referred-to branch (e.g., .git/refs/heads/master, or from packed refs).
If no SHA-1 is available because branch does not exist yet, create root commit, else create commit whose parent is the given SHA-1.  Write new SHA-1 to referred-to branch.  Stop, we are done.
As an interesting side note, when refs get packed, "active" ones (like whichever branch you're developing on, let's say devel for instance) wind up in .git/packed-refs, but are quickly updated with new values.  Those new values go only in the .git/refs/heads/devel file: the .git/packed-refs file retains a refs/heads/devel entry, but it's stale (and hence ignored).  (You're not supposed to depend on this: external programs, such as shell scripts, should use git branch or git update-ref or git symbolic-ref as appropriate, to read and write ref-names and SHA-1 values.  Occasionally, though, it's useful to be able to go in and edit refs directly.  Think of it as a modern-day equivalent of a hex editor for disk sectors. :-) )



1This all assumes you are not creating a merge commit.  If you are in the middle of a merge, another file in the repository (.git/MERGE_HEAD) supplies the extra merge parent IDs.

                        
这篇关于没有主分支的Git仓库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！