git group development server setup

Question

I want to deploy git for my organisation. I want users to have no access to the server and to make commits only to the repository. However I want the repository to be a real file system that I can use with an apache virtual host. What I have done is the following:

cd /home/vhosts
git init --shared {projectname}
git config receive.denyCurrentBranch ignore

I then want to run git reset --hard after every push back to the main repository.

Is this a good idea? Should I have a second repository that does a git pull instead of a git reset --hard... which is heavier? Can I set this up to be a hook??

Thanks.

Answer 1

Typically the way to set this up is to have a "bare" repository that is the top level master that everybody pushes and pulls from. The web server running Apache has its own separate repository (if you're short on hardware, they can be on the same machine). You would install a post-commit hook on the master repository that triggers a "git pull" on the one for Apache under /home/vhosts. (This hook is simplest on one machine, but you can do it across machines if you set it up that way.)

To create a bare repository:

mkdir -p /home/git/{projectname}.git
cd /home/git/{projectname}.git
git init --shared --bare

A bare repository has no working copy at all, just the contents of the .git structure.

Answer 2

I'm not sure what Apache has to do with it.

Just setup a repo, a bare one as Greg says, and have that be your main repo. People then pull from that, and when they're ready they push to it. You probably want to deny non-fast-forward merges on the main repo, so that people always pull the latest code, merge with it, and then push.

The best way to give people access to the repo is using the git daemon and the git:// protocol.

If you want a web interface then use gitweb, but that's just a convenience.

Also there is some good discussion of different workflows in section 5.1 of the Pro Git book, which might help clarify what the best workflow is for you.

Answer 3

I have the setup you describe with a few modifications. Joe Maller has an excellent write-up that I used as a base for my configuration. A web-focused Git workflow