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.
Sadly, there's not a good solution in this space yet. The community would welcome anything you can whip up, or you can call Reductive Labs and give them some consulting business. I looked at doing this awhile back and found it to be a little more challenging than I had time to tackle.
Feel free to hit up the IRC channel (#puppet on Freenode) - there are a lot of really helpful folks there who would be glad to offer advice/assistance, especially if it leads to a tool that is contributed to the Puppet ecosystem.
Best Answer
I disagree with Graig Watson.
Creating copies of accounts means you've then got problems keeping them in sync. Having a single source for authentication information eliminates a lot of complications and LDAP is much easier to integrate into other services (web, mail etc).
In terms of sudo access - if you configure your sudoers based on groups rather than individuals then access to the facilities can easily be controlled via LDAP. It requires more forward planning - but is much easier to manage in the longer term - you manage the security policy not data files.
Making ssh keys available on other machines is best handled by using some sort of network file system - it might be NF/Samba, but replicating or shared filesystems provide the same goal (with different side-effects).
The first step should always be defining your security model - allowing local configurations gives huge scope for undermining that model.