master TOC | main page | single-page | license
This is for gitolite "g3"; for older (v2.x) documentation click here
Git by itself does not do any access control -- it relies on the transport medium to do authentication ("who are you?"), and on OS file permissions to do authorisation ("what are you allowed to do?").
Git also comes with a program called "git-shell" which can act as a restricted login shell if you don't want users getting a proper shell. Using this and judicious use of Unix groups, you can allow some people read-only access while others get read-write access, etc. This is probably sufficient if your needs are simple and don't change too often.
However, gitolite does this much better, and offers many more features.
Gitolite is useful in any server that is going to host multiple git repositories, each with many developers, where "anyone can do anything to any repo" is not a good idea. Here're two examples to illustrate.
Example 1, 3 repos, 3 developers with different levels of access to each repo:
repo foo RW+ = alice R = bob repo bar RW+ = bob R = alice repo baz RW+ = carol R = alice bob
Example 2, one repo, but different levels of access to different branches and tags for different developers:
repo foo RW+ master = alice RW+ dev/ = bob RW refs/heads/tags/v[0-9] = ashok
If you're a masochist, you could probably do example 1 with Unix permissions and facls. But you can't do example 2 -- git is not designed to allow that!
Here are some other disadvantages of the Unix ACL method:
usermod -G ...mumblings (I.e., the "pain" mentioned above is not a one-time pain!)
The best real alternative to gitolite is Gerrit Code Review. If code review is an essential part of your workflow, you should use Gerrit.
Here're some high level differences between gitolite and Gerrit:
Size: 3000+ lines of perl versus of 56,000+ lines of Java
Architecture: Gitolite sits on top of "standard" git and openssh, which are assumed to already be installed. Gerrit includes its own git stack (jgit) and sshd (Apache Mina). In Java tradition, they all come bundled together.
(Corollary: As far as I know jgit does not support the same hooks that 'man githooks' talks about).
Gitolite uses a plain text config file; gerrit uses a database.
User view: Gitolite is invisible to users except when access is denied. I think Gerrit is much more visible to devs.
On a related note, gitolite does not do anything special with signed or annotated tags, nor does it check author/committer identity. However, it is trivial to add your own code to do either (or if someone contributes it, to just "enable" what ships with gitolite in a disabled state).
Anecdotally, gitorious is very hard to install. Comparison with gitolite may be useless because I believe it doesn't have branch/tag level access control. However, I can't confirm or deny this because I can't find any documentation on the website. In addition, the main website hides the source code very well, so you already have a challenge! [The only link I could find was tucked away at the bottom of the About page, in the License section].
Gitorious has several, much newer, competitors offering web-based management, issue tracker, wiki, and so on; try googling for gitlab, gitblit, and rhodecode.
However, to the best of my knowledge none of them offer branch level access controls (please tell me if you know different), which, since it is the main reason I wrote gitolite, makes them all somewhat moot.
They are also unlikely to be as customisable as gitolite is, if you care about that sort of thing.