Managing GIT permissions - multiple repositories

Question

We have several development teams, each of which develop multiple projects (10+ usually). We are currently in CVS and evaluating whether to move to SVN or GIT. I am leaning towards GIT, however I am not sure how we can manage the permissions efficiently. For example.

We have Dev Team A, Dev Team B, Dev Team C. Each of which have 12 developers. Each Dev Team has at least 10 separate projects. Team A can see everyone's code, Team B and C can only see their code. Additionally some developers only have Read Only access while others have Full access.

So in CVS we have three repositories, one for each team. So it's like:

/cvsroot/TeamARepos/project1
/cvsroot/TeamARepos/project2

/cvsroot/TeamBRepos/project1
/cvsroot/TeamBRepos/project2 

/cvsroot/TeamCRepos/project1
/cvsroot/TeamCRepos/project2 

and so on. I can manage the whole repository and say John Doe has read only access to A but write access to B and no access to C - and therefore I don't have to give him explicit access to each project (and they get added pretty frequently, so I don't have to add everyone to every new project each time).

My understanding of GIT is that I would have one repository per project. So there isn't a real logical way to say 'all of Team A's code is here and these users can write to it' and 'all of Team B's code is here and these users can read it' and keep it separated like that.

I'm not sure I even know how to ask the question right - but I envision moving to GIT as an administrative nightmare.

We also use ant scripts to check code out of CVS, do the builds, and deploy to the servers. I have just started to look but I'm hoping ant plays well with GIT in that sense too.

Answer 1

I suggest using git over svn because of its speed, distributed version control model, and overall sane way of doing things. We were using SVN at work for a few years, and it was a real pain compared to git. The only advantage I saw with SVN was its integration to Windows with e.g. TortoiseSVN. But that's only if you like to be constrained by the GUI, and are not willing to learn the much more powerful command line.

With git you clearly need gitolite to handle the access control. With this model you set up a different repository for each project. Gitolite configuration file allows you to group developers into teams, and then you can set up very fine grained access control per repository, branch, or even working tree path. You can specify the permissions in terms of teams, or individual persons, whichever way suits you best.

If you need code review, you should also check if gerrit is the right tool for you. You don't need both, use either gitolite or gerrit.

Sometimes people find git hard to learn. For that, I suggest to point the developers to a good book, for example this. It's also available in print.