Set Up Your Own Private Git Hosting

09 October 2010

First off, I love Github. I am a paying customer and likely always will be. So, I am not suggesting replacing your use of that service with this setup. However, I have a few things that are just random projects I like to put on version control which I don't really want to be "public", but are not worth taking up a private repository on my account (repositories of SVG files for work, etc). Since I have an EC2 instance set up and running already, I decided to set up my own git "host" server.

Overview

You can set up basic git hosting quite easily over any SSH connection (follow this tutorial). However, I wanted to take it a step further so it would be easy to both maintain for myself and to easily maintain some repositories for any friends in need of a (free) private repository.

As far as I can tell, there are basically two options you can use to set this up:

  1. Gitosis (github fork)
  2. Gitolite

Similarities

At a high-level, they offer the same functionality: you have an "administration" git repository which you modify, commit, and push to your server in order to create repositories and manage access privileges. So, you have a list of usernames and their public keys in one area/file and another file which you say "user_x can read/write to repository_1", etc. You commit & push that to the server, and "Boom!" the user can clone & push to that repository...just like when you create a repository on Github.

Another notable similarity is that both are widely-used AND used by high-profile projects/vendors, so they likely won't "go stale" any time soon. I believe both Github and Heroku use gitosis and the Fedora and KDE projects both use gitolite. I am sure other well-known companies use both...those are just some big-names I have run across. (Correct me if I am wrong on any of them)

Differences

My take on the primary difference between the two options is the granularity of permission control: gitolite allows more fine-grained control than gitosis. Gitosis is similar to how it works on Github, if a user has privileges to push to a repository, they have full privileges to do whatever they want to that repository. Gitolite allows you to (1) restrict read/write privileges at the branch/tag-level (using regular expressions, even) and (2) to restrict permission to push "non-fast-forwardable pushes". These two features make gitolite a more likely candidate to be "allowed" in a corporate setting.

Note:
If #2 doesn't make any sense, it basically means you can restrict the ability for someone to, say, rebase on the history of a repository and do a "push -f", which is a huge PITA for everyone who has a clone of that repository.

Other notable information I ran across:

gitolite:

  1. ...is under more active development (at least as of Oct-2010)
  2. ...is little easier to set up. I've set up both and neither are horrible to set up, but gitolite is definitely easier. If you have passwordless logins set up on the server, you essentially just have to run a shell script from your local machine.
  3. ...makes working with gitweb and git-daemon a bit easier...if you want read-only public access. (If you are interested, you just use deal with special "gitweb" and "daemon" user accounts like any other user account...really straightforward).
  4. ...has better project documentation (in the "docs" directory of the project source)
  5. ...has a really easy upgrade process (just re-run the setup script).

gitosis:

  1. ...has more examples/discussions in blogs, discussions, and mailing lists (from my impression)

Summary

The setup for both systems is well-documented in the ProGit book (gitolite, gitosis). I ended up going with gitolite for the following reasons:

  1. I had set up gitosis before and I wanted to compare them
  2. The administration seemed both more simple and powerful
  3. If I want to try to pitch installing it at work, the "per-branch" access control would likely be a "plus" in the list of features. I want to understand how it works in the event that happens. (I presently work in a large-ish company)

In the end, I guess I don't think it really matters which one you set up. However, I think you should set up one of them...even if it's for no reason other than to get a little better understanding of how Github, Heroku, and other similar sites/services work.