Git repository created without a master branch

Question

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 br

Answer 1

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 -A
git commit -m "initialize"
git branch

Answer 2

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.git and 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_origin repo form there.

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

Answer 3

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.
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 HEAD and 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.

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. :-) )

---

¹This 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.