Check out gitosis which is a git repository hosting application. Quoting the description from the Debian package of gitosis:
This package aims to make hosting git repositories easier and safer.
It manages multiple repositories under one user account, using SSH
keys to identify users. End users do not need shell accounts on the
server; they will talk to one shared account that will not let them
run arbitrary commands.
You can find the gitosis source at http://eagain.net/gitweb/?p=gitosis.git
Documentation on how to set it up:
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
I'm very happy with gitosis, we're using it at the grml project (http://grml.org/) with more than 100 repositories and it works fine without any problems.
Permissions are a pest.
Basically, you need to make sure that all of those developers can write to everything in the git repo.
Skip down to The New-Wave Solution for the superior method of granting a group of developers write capability.
The Standard Solution
If you put all the developers in a specially-created group, you can, in principle, just do:
chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo
Then change the umask for the users to 002, so that new files get created with group-writable permissions.
The problems with this are legion; if you’re on a distro that assumes a umask of 022 (such as having a common users group that includes everyone by default), this can open up security problems elsewhere. And sooner or later, something is going to screw up your carefully crafted permissions scheme, putting the repo out of action until you get root access and fix it up (i.e., re-running the above commands).
The New-Wave Solution
A superior solution—though less well understood, and which requires a bit more OS/tool support—is to use POSIX extended attributes. I’ve only come to this area fairly recently, so my knowledge here isn’t as hot as it could be. But basically, an extended ACL is the ability to set permissions on more than just the 3 default slots (user/group/other).
So once again, create your group, then run:
setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX
This sets up the extended ACL for the group so that the group members can read/write/access whatever files are already there (the first line); then, also tell all existing directories that new files should have this same ACL applied (the second line).
Hope that gets you on your way.
Best Answer
I recently setup a Git server where I work which required SSH and HTTP(S) access for public and private repositories. I first setup the entire thing manually which took some time, but then I came across Gitlab which seemed to solve all my problems - it's pretty much Github, but your own private hosted version. I'd strongly recommend using Gitlab over setting everything up manually, given that it has so many great features and is easily manageable.
There's a great tutorial here: https://github.com/gitlabhq/gitlab-recipes/blob/master/install/centos/README.md
However, if you do want to run Git through HTTP(S), you will need to setup Apache or Nginx to use the git-http-backend binary which does all the work. There are plenty of tutorials online depending on which configuration you decide to go with.