That's a pretty new topic for me.
I've been setting up a shared box for development purposes. I went for the simplest setup possible, which required three "features":

• /etc/group
  
• POSIX ACLs
  
• chmod's sticky bit
  

The first thing to do was to create a group for everyone. Let's say "devs". Once the group is set up, you can create a "work place" for everyone.
I'm still not sure where such a place should be on a linux system... I chose /ns/$PROJECT, "ns" meaning "namespace" here. But I don't think there is a POSIX or even FHS compliant place for such a thing.

Once the directory exist, there are two things one can do. First, I set the group owner to "devs", and make the group sticky, so that every inode created under this directory will inherit the group:


Of course, this lacks write permissions for the group, but instead of using the traditionnal Unix permissions, we'll use the POSIX ACL (access control list) to finer tune the access. Beware, not all filesystems support ACLs.
One "limitation" of the unix permissionning system is that you can't make subfolders or files "inherit" the permissions from their parents. New files/directories will have the permissions set by the umask. And sadly, it's named 'umask', not 'gmask'. One could "force" the users of the "devs" group to use umask "002" but it's far from efficient, as the users can easily override it and mess up your project.

POSIX ACLs permit that:


Both notations are the same. This will set the "default" permissions on the "group" field to "devs" with "read + write" access to the /ns/$PROJECT directory, and all its subtree. Because "rw" is the default doesn't mean it's limited to this permission. You can still change the permissions with "chmod", or even use "setfacl" against a specific subfolder.