gitosis vs gitolite? [closed]

Question

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@]server
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

Locally:

cd projects/are/here/project
git remote add origin [user@]server:repos/are/here/project.git
git 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 [email protected]

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.

For an even quicker and dirtier solution, just use git daemon and go peer-to-peer. Here's an article about doing just that.

Edit: I recognize this doesn't strictly answer the OP's question. I put this here mainly for those, like me, who come across this while looking for a down and dirty way to share code until an enterprise github account gets set up.

I have been messing around for a while to get a git server working with LDAP access, fine grained access control etc... Found a revelation: Use Gitlab:

• git repositories
• fine grained access (afaik gitlab uses gitolite under the hood)

if you want the quick and fast installation method: use the bitnami installer