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.

As Rajeev has pointed out in comments, Active Directory IS an LDAP server and more, and the AD LDS service is a "free" Windows Server role that is provided to do specifically what he is looking for. AD provides many extras (replication, Kerberos, federation, etc.) that you would have to build on your own with a Free/OSS solution like OpenLDAP+postgres+kerberos. There are other (primarily commercial) directory services which have similar abilities.

Licensing should probably not be an issue. You are probably going to have AD installed if your deployment is going to be primarily Windows-based (for the computer accounts, admin accounts, etc.), and this will be relatively small (looks like a 5-user CAL at most). Any "user" objects that you create in LDS for your public users will not be counted against the licenses for your AD DS accounts. You can contact Microsoft Licensing to verify this.

Using AD LDS definitely has some great benefits, your proposed installation may be too small to realize some of them though.

1. Replication is probably the #1 "freebie" you get with LDS. Your AD DS Sites and Subnets topology can be used to manage replication automatically, just like for AD DS. But with only one LDS server, you won't need replication.
2. Most of the newer tools for backup, maintenance, reporting, etc. will all work as well with LDS as they do with DS. So, if you already have some off-the-shelf tools in-house, you can probably just use them for your LDS. Again, your setup sounds too small for this to be a big benefit.
3. If you are ALREADY familiar with the care and maintenance of AD DS, using LDS will be generally familiar and will build on a knowledge-set you already have. This can mean significant improvements in supportability and manageability, any scripting knowledge you have will be generally transferrable, etc. This is a bonus.
4. And again, LDS is "free" with Windows, if you've installed a 2003/2008 server then LDS is included. This is also a bonus.
5. With Windows Server 2008 R2 you get all the cool features from the AD DS code-base (snapshots, etc.)

All that said... If you don't have any particular experience with AD, and don't have any particular infrastructure already in place to handle it, you may not see much benefit by going this route. Based on the size of your described deployment, you could almost certainly go with an OSS setup like LAMP + OpenLDAP, depending on your comfort-zone and what you are application requirements are.

Keep in mind that if you are doing any kind of user management, then you are going to very, VERY sorry if your approach is just "stick a bunch of user names and passwords in a SQL table." User management is a complex process that has already been solved countless times before. Handling passwords is something you just should not be doing unless you already have lots of experience in security related programming. Please don't roll your own!

Find a suitable commercial or OSS framework that has been designed already to handle AAA* correctly, something like OpenID is probably not a terrible idea. Jeff Atwood's blog (he runs a website, you may have heard of it...) has a number of posts discussing these issues around his work on StackOverflow and ServerFault.

Any way, I hope this discussion helps.