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.

Using the example of my copy of Puppet checked out from the upstream Git repository on Github.com...

$ git remote show origin
* remote origin
  Fetch URL: git://github.com/reductivelabs/puppet.git
  Push  URL: git://github.com/reductivelabs/puppet.git
  HEAD branch: master
  Remote branches:
    0.24.x                 tracked
    0.25.x                 tracked
    2.6.x                  tracked
    master                 tracked
    next                   tracked
    primordial-ooze        tracked
    reins-on-a-horse       tracked
    testing                tracked
    testing-17-march       tracked
    testing-18-march       tracked
    testing-2-april        tracked
    testing-2-april-midday tracked
    testing-20-march       tracked
    testing-21-march       tracked
    testing-24-march       tracked
    testing-26-march       tracked
    testing-29-march       tracked
    testing-31-march       tracked
    testing-5-april        tracked
    testing-9-april        tracked
    testing4268            tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Then if I were to execute the following:

$ git checkout -b local_2.6 -t origin/2.6.x 
Branch local_2.6 set up to track remote branch 2.6.x from origin.
Switched to a new branch 'local_2.6'

And finally re-run the git remote show origin command again I will then see the following down near the bottom:

  Local branches configured for 'git pull':
    local_2.6 merges with remote 2.6.x
    master    merges with remote master