gitosis vs gitolite?

Question

I am looking for installing a git server to share projects with my team. I don't want to create a user account on the server with SSH access for each developer that needs a git access. It seems there is two concurrent solutions that cover this issue : gitosis & gitolite.

I could not find any comparison between both solutions. What are the main differences between them? Are there other similar solution?

Solution 1

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

Solution 2

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...

Solution 3

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.

Solution 4

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.

Solution 5

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

View more solutions

Comments

[Andrew T Finnell]

After installing the beast that is GitLab+Gitolite, if you don't need fine control over projects etc, this is way to go.

[greydet]

Thank you for this answer! Actually when I said that I did not want to create user accounts for each, I should have also mentioned that I don't want my git users to have access to the server shell through ssh. With your solution I think they would have access to the shell through the "git" user, right?

[wsams]

For the no-install solution, I had to use git push origin master instead of just git push.

[ThiefMaster]

@wsams: git push -u origin master and you can use git push after it. I prefer gito* because in my opinion nobody accessing a repo should have to care about the absolute path it has on the remote system.

[AD7six]

@ThiefMaster taking a wild guess at what you mean, if you put repos in /home/git/ the url to access a project is git@server:project.git.

[fabspro]

@wsams read this part of the answer "Change the git user's shell to be git-shell".

[wsams]

This is a normal user - I wouldn't want to use git-shell @fabspro.

[complistic]

I've been using Gitolite for over 3 years now. Never had any problems with it. I our production and staging servers have read-only access to the repos the need. And its an easy job to then share a project with other Development teams. Also it's easy to setup if you know unix and git already :)

[VonC]

Yes, but GitLab (with gitlab-shell) lost all the VREF hooks that you could easily setup with Gitolite. And a lot of people would like them back: github.com/gitlabhq/gitlab-shell/issues/14 and github.com/gitlabhq/gitlab-shell/pull/85

[Quinn Comendant]

Gitolite documentation includes comparisons to alternatives: gitolite.com/gitolite/gitolite.html#alt