gitosis vs gitolite? [closed]

I am looking for installing a git server to share projects with my team.

You can just use git.

To have a git server the only thing you need on the remote server is git. If you don't require fine-grained permissions (sharing with only your team suggests that's a possibility) or any extra features, you don't need gitolite, or similar.

The no-install solution

If git is available on the remote server, you can do what you're asking right now, without doing anything

ssh [user@]servercd repos/are/here/mkdir project.gitcd project.gitgit init --bare

Locally:

cd projects/are/here/projectgit remote add origin [user@]server:repos/are/here/project.gitgit push -u origin master

Setting up a git server is easy.

If you want to do things with a dedicated git user, the docs for setting up a git server are short - because it really is quite easy to do.

In summary:

• Install git
• Create a user named git
• Add your and your team's public keys to the git user's .ssh/authorized_keys file
• Change the git user's shell to be git-shell
• Create repos on the server
• start git pull/pushing to git@yourserver.com

The only difference between using a dedicated git user and not, is that if you setup the git user to use git-shell it won't allow itself to do anything else. In terms of acting as a git server though, it's identical to the no-install solution

The main difference is that gitosis is now obsolete, and not actively maintained anymore.

Gitolite is much more feature complete, and just released its third version.

Its most interesting feature is the Virtual Reference (VREF for short) which allows you to declare as many update hook as you want, which allows you to restrict a push by:

• dir/file name:
  Say you don't want junior developers pushing changes to the Makefile, because it's quite complex:
  - VREF/NAME/Makefile = @junior-devs

• number of new files:
  Say you don't want junior developers pushing more than 9 files per commit, because you want them to make small commits:
  - VREF/COUNT/9/NEWFILES = @junior-devs

• advanced filetype detection:
  Sometimes a file has a standard extension (that cannot be 'gitignore'd), but it is actually automatically generated. Here's one way to catch it:
  - VREF/FILETYPE/AUTOGENERATED = @all
  See src/VREF/FILETETYPE to see the detection mechanism.

• checking author email:
  Some people want to ensure that "you can only push your own commits".
  - VREF/EMAIL-CHECK = @all
  See src/VREF/EMAIL-CHECK.

• voting on commits:
  A basic implementation of voting on a commit is surprisingly easy:
  - VREF/EMAIL-CHECK = @all.
  # 2 votes required to push master, but trusted devs don't have this restriction
# RW+ VREF/VOTES/2/master = @trusted-devs
# - VREF/VOTES/2/master = @devs
  See src/VREF/VOTES for the implementation.

• and so on...

Just a sidenote. You can also use Gerrit for your needs:

Gerrit Code Review

First it seems that Gerrit is used for Code review, but you can actually use it also for managing users and give them good defined permissions. You can bypass code-review(trough access controls) and use it just for managing projects and ssh-keys. Gerrit has a really strong access control mechanism:

Gerrit Access Controls

You can restrict to push for any branches, tags or anything you can imagine that is defined in the access controls document.