Git - why "shared repositories should be bare repositories"? Is this obsolete advice?

Question

I'm new to git and Github. I have learned many of the terms (push, pull, commit, branch, etc), but I'm going to mostly use common parlance to explain my initial expectations.

I assumed the process was:

1.) Create a git repo out of my existing files.
2.) Copy those to my Github account to create a central "hub".
3.) Anyone who works on the project will check it out from Github, do work on their computers, then upload the changes to the hub.
4.) Anyone else working on the same branch can easily upload their changes as well, and will be warned if there are any conflicts. They can also easily download changes since their last download to update their local copy.

So I did step 1 and 2. And I created a few branches. I've made a few commits and pushed the changes to Github. I also cloned the master branch on another machine, and then branched off of that. I pushed the new branch to Github. Everything seems to be working fine. But now, as I prepare to add other developers to the project, I've come across repeated admonitions that the "central" repository should be "bare."

Here, here ("it's not recommended to push into a non-bare repository"), and atlassian says "Central repositories should always be bare repositories", and several other places. Apparently, if it's not bare and someone else pushes a new file, then my local version will consider itself to have deleted that file when I push. I'll end up undoing the work of other developers, the very problem I was trying to fix with git!

That has me worried, since I've already set up my Github project with a bunch of files. I was about to set to work figuring out who to convert my hub to a bare repo, when I came across some information that suggests that with newer versions of Git, you don't need a bare repository at the hub. I think it has to do with version 2.3 having updated behavior for git push. Is that true and why?

And what do I do if my local Windows machine has version 2.7, but another CentOS machine is using 1.7.1?

Answer 1

The problem with non bare repositories is that they have a checked-out branch, and if someone pushes to that branch, then things go weird: The working copy and the index will be behind the branch. That should not happen in a normal workflow: imagine what will happen if just after receiving a pushed branch in your non-bare main repo, you do a one-line commit? Your commit would actually roll back all the received changes, without even adding any file to the index.

GitHub repos are bare. Although you can see the files and the branches, there is nothing actually checked out (you cannot commit in a github branch directly!).

Answer 2

The GitHub repositories are always bare, so you have nothing to worry about.

The advice still holds. The change in version 2.3 has to do with which branches are pushed by default.

Answer 3

I see that rodrigo has already given the right answer and the reason for it, but given the question ("is this obsolete") I want to add something. It's is not obsolete advice (and probably will never be), but git has added a new ability "out of the box" as it were:

receive.denyCurrentBranch
[snip]
Another option is "updateInstead" which will update the working tree if pushing into the current branch. This option is intended for synchronizing working directories when one side is not easily accessible via interactive ssh (e.g. a live web site, hence the requirement that the working directory be clean). This mode also comes in handy when developing inside a VM to test and fix code on different Operating Systems.

In other words, if you have a non-bare repository that you want to use both as a repository (not just a raw deployment) and as a deployed (but not edited) tree, you can now do that.¹ This has been in place since git version 2.3, with a minor fix² in version 2.4.

The way to use it is simple—simpler than the fancy deployment mechanisms people put into post-receive hooks, so perhaps worth the extra space-cost of keeping a complete repository. You simply clone the repository where you want the tree to wind up, check out the branch you want deployed here (or add -b to the clone command), then use git config to set receive.denyCurrentBranch to updateInstead:

$ git clone -b staging <url>
$ cd <repo>
$ git config receive.denyCurrentBranch updateInstead

and now anyone who pushes to staging in this new clone will update the checked-out staging branch, provided no one touches it to cause it to become "dirty".

---

¹Technically it has always been possible, by setting receive.denyCurrentBranch to false and writing a post-receive or update hook that "did the right thing", but it was kind of error-prone.

²The fix is that you can push to an unborn branch as well now. That is, if you did a git clone then did a git checkout -b to create a new branch, but have made no commits on it yet, you can now cause that branch to become a "real branch"³ with a git push, as long as the remaining conditions (clean index and work-tree) are met.

³A new but "unborn" branch exists only as a symbolic reference in the HEAD file, not as a refs/heads/<branch> file or entry in the packed-refs file. This means that if you do another git checkout to some other branch, the unborn branch vanishes, with no sign it ever existed. In that sense one might call it a "virtual" branch, or at least "not quite real".