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
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.
if you created the repository (or cloned a new bare repo off an existing one) with
$ git init --shared=group
$ git init --shared=0NNN
Git is supposed to handle permissions above and beyond what your default umask provides. At last this is true on my version of Git (1.6.3). Of course this assumes your users are in the same group.
If I needed management of users in multiple groups with varying degrees of read/write however, I’d go with gitosis. I have also heard mention of gitolite (http://github.com/sitaramc/gitolite), a gitosis fork that is suppossed to provide branch level permissions, can’t say I’ve every used it personally though.
This has not been said, so I want to quickly add it.
To ensure that permissions issues do not crop their ugly head, make sure to set the following on your git shared repository’s config file:
[core] sharedRepository = true
This will ensure that your system’s “umask” settings are respected.