Nothing different if you're okay with having real system Unix accounts for your developer on a target system. The only problem is short pathnames of projects but I'll show ways to deal with it after explaining the basic setup.
The main premise to make things work is that your Git-repositories should be group-shared. Git has support for this, but for convenience you'd better off helping it to do its part of the work properly.
1) Install Git. There's no special "server-side Git" binary if you intend to access your repositories using SSH [*], so just install Git like apt-get install git.
2) Make sure all your system accounts for Git developers are members of a single special group -- be it "devel" or "git", -- it doesn't matter. Suppose we've picked "git" for this.
3) Create a central place for your repositories. On a typical GNU/Linux system conforming to FHS, I'd recommend to create the "/srv/git" directory (you already have "/srv") and make it belong to root:git and have access rights 2755 (or 2750 if you're paranoid), that is, group writable with group sticky bit set on.
4) For each of your project, create a *bare, shared* repository by running something like this:
# cd /srv/git
# umask 002
# git init --bare --shared project1.git
Verify that the created project directory and its files have sensible access rights -- the "--shared" option which is short for "--shared=group" ensures the directory is group-writable and has group sticky bit set on it, and the step (3) should have made the directory's owning group to be "git".
5) Now try to push something to is from a client:
git remote add origin ssh://me@my-server.com/srv/git/project1.git
git push origin master
You can now see that you can't easily drop the leading part of the project's directory pathname from the remote repository's URL because there's no layer of indirection when accessing Git repositories via SSH: the client Git process just spawns another Git process on the remote machine after setting up an SSH channel, and hands it off the pathname. The only supported shortcut is ~ with the expected meaning.
I'd say that is not really a problem because:
1) Most of the time you're working with named remotes, so you only have to type in the URL once.
2) If the repositories are located in a somewhat standardized place (/srv/git), the leading pathname part is not a big deal to type.
Anyway, there's another approach which is a layer of indirection between you and Git. These days, a low-level de-facto standard tool for this is gitolite [https://github.com/sitaramc/gitolite]. It provides *virtualized* Git users (so that you only have one system account to access Git repositories, and still each developer has their own SSH key), repository- and branch-level access controls, and more. And as a by-product, since it requires all the repositories be located under a single directory, and it knows which one, it provides for short-cut syntax, like
ssh://me@my-server/myproject
[*] There's a special Git daemon, unsurprisingly called git-daemon, which is able to serve Git repositories: unauthenticated and hence read-only (but you can turn certain knobs to make it serve R/W as well--in certain controlled environments this might be OK to do). This daemon works kind of like svnserve in that it allows to specify a base directory for the projects using its "--base-path" command-line option.
