在没有主分支的情况下创建的 Git 存储库

Git repository created without a master branch

提问by Ayelet

I want to create a new shared git repository for a new project (on a VM).

我想为新项目（在 VM 上）创建一个新的共享 git 存储库。

I ran git --bare initfrom /.../git/new_proj.git, but a master branch is not created in the .../git/new_proj.git/refs/headsdirectory. I also ran sudo chmod 777 -Ron my directory, but it didn't help, and still no master is created after the initcommand.

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

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

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

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

谷歌在这件事上没有太大帮助......

Anyone know what the problem is? Something I'm missing? Thanks!

有谁知道问题是什么？我错过了什么？谢谢！

回答by torek

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 HEADin the repository (the .gitdirectory), containing a symbolic branch name reference. If you cat HEADyou'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.

它确实有一个HEAD，这是一个HEAD在存储库（.git目录）中命名的文件，包含一个符号分支名称引用。如果您cat HEAD会看到ref: refs/heads/master，这意味着新存储库“在 master 分支上”，即使分支 master 尚不存在。同样，这是完全正常的事态。在这一点上，您被称为“在未出生的分支上”。

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

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

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:

在任何回购（无论是否裸露）中，您都可以“在”一个不存在的分支。特别是，在普通的 repo 中，您可以执行以下操作：

$ git checkout --orphan newbranch

which puts you "on" newbranch(by writing ref: refs/heads/newbranchinto HEAD) without actually creatingnewbranchyet, making newbranchan "unborn branch". The next commit then causes newbranchto come into existence, and that commit has no parent commits (hence the --orphanpart): it is a new root commit. This is the same way mastercomes into existence on itsfirst commit.

其中“关于”把你newbranch（通过编写ref: refs/heads/newbranch成HEAD），而不实际创建newbranch的是，制作newbranch一个“未出生的分支”。然后下一次提交导致newbranch存在，并且该提交没有父提交（因此是--orphan部分）：它是一个新的根提交。这是同样的方式master进入上存在它的第一次提交。

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

如果你喜欢，你可以从底层机制来看：当 git 创建一个新的提交时，用于更新的步骤HEAD是这样的：¹

1. Read contents of HEADfile.
2. Is it a symbolic ref such as ref: refs/heads/master? if yes, go to step 4.
3. No ("detached HEAD" case): create commit with parent given by commit ID in HEADand write new SHA-1 into HEAD. Stop, we are done.
4. Read SHA-1 of referred-to branch (e.g., .git/refs/heads/master, or from packed refs).
5. 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.

1. 读取HEAD文件内容。
2. 它是一个象征性的 ref，例如ref: refs/heads/master? 如果是，请转到步骤 4。
3. 否（“分离的 HEAD”情况）：使用提交 ID 给出的父项创建提交HEAD并将新的 SHA-1 写入HEAD. 停下，我们完成了。
4. 读取被引用分支的 SHA-1（例如.git/refs/heads/master，，或来自打包的引用）。
5. 如果由于分支尚不存在而没有可用的 SHA-1，则创建根提交，否则创建其父项是给定 SHA-1 的提交。将新的 SHA-1 写入被引用分支。停下，我们完成了。

As an interesting side note, when refs get packed, "active" ones (like whichever branch you're developing on, let's say develfor instance) wind up in .git/packed-refs, but are quickly updated with new values. Those new values go onlyin the .git/refs/heads/develfile: the .git/packed-refsfile retains a refs/heads/develentry, but it's stale (and hence ignored). (You're not supposed to depend on this: external programs, such as shell scripts, should use git branchor git update-refor git symbolic-refas 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. :-) )

作为一个有趣的旁注，当 refs 被打包时，“活跃”的（比如你正在开发的任何分支，比方说devel）结束在.git/packed-refs，但很快就会用新值更新。这些新值只存在于.git/refs/heads/devel文件中：.git/packed-refs文件保留了一个refs/heads/devel条目，但它是陈旧的（因此被忽略）。（您不应该依赖于此：外部程序，例如 shell 脚本，应该使用git branchorgit update-ref或git symbolic-ref适当地读取和写入 ref-names 和 SHA-1 值。但有时，能够去in 并直接编辑 refs。将其视为现代磁盘扇区的十六进制编辑器。:-) )

---

---

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

¹这一切都假设您没有创建合并提交。如果您正在进行合并，则存储库中的另一个文件 ( .git/MERGE_HEAD) 会提供额外的合并父 ID。

回答by Bafi

i have same issue and fixed - first of all use git add command after that use commit command finally use git branch to show your branched my git version 1.9

我有同样的问题并已修复 - 首先使用 git add 命令，然后使用 commit 命令最后使用 git branch 来显示你的分支我的 git 版本 1.9

git add -A
git commit -m "initialize"
git branch

回答by gravetii

Bare git repos (repos created by issuing git init --bare) will not have a working tree attached to them. What you can do is go to the repo /.../git/new_proj.gitand add the bare repo you created as a remote: git remote add bare_origin <link to bare repo>and then try pushing your commits to this bare_originrepo form there.

裸 git 存储库（通过发布创建的存储库git init --bare）不会附加工作树。您可以做的是转到repo /.../git/new_proj.git并将您创建的裸存储库添加为远程：git remote add bare_origin <link to bare repo>然后尝试将您的提交推送到此存储bare_origin库表单。

Also, do you have any particular reason in creating a bare repository instead of a normal one?

另外，您在创建裸存储库而不是普通存储库时有什么特别的原因吗？