I hesitate to write about Gitolite. Why? Because I'm adding to an already voluminous amount of documentation on the subject. What, yet another article on Gitolite. Why so much documentation on Gitolite, because, although there are many claims in the documentation that Gitoite is easy to install, if you start running into problems, it's not. Anyone who has run into problems, wants to help others, and thus writes more documentation on the subject. I had a ton of problems loading Gitolite, and I've read just about every article and series of questions and answers on Gitolite on the Internet.
Why not just give up, if you run into problems, and use GitHub? Because I did finally get it installed, and the effort to get it installed correctly is worth the effort.
What was missing from all that I read was an overview, a guideline and road map through the installation process. This is an overview on getting Gitolite and GitWeb installed and running correctly. The why behind all the commands you see in the documentation.
First, when would you want to use Gitolite, what is it?
The reason to use Gitolite is, if you want to have a central master repository of your work, to which, several developers contribute. Gitolite makes it easy to exchange work between developers. Why not GitHub? Well, GitHub is on the Internet, and some corporations do not want their work on the Internet. They want it on one of their internal servers, not available to the outside world. If that's the scenario, your best choice is Gitolite.
Git has two types of repositories, the every day repository that saves your local work on your local machine with a commit, and a "bare" repository. A "bare" repository can only be updated with a "git push" or "git pull". You use the bare repository on your central server as your master repository. Git will not make commits on a bare repository, so no changes are possible directly on the server. You have to get code from the repository with a "git pull," and make updates with a "git push" from a regular repository on your local machine.
A group of developers will develop code on their local machines, each using their own pet development tools, and make commits to their local repository. When they get ready to share their code with other developers, they first pull and then push their work to the bare repository on the central server.
Gitolite is an administrative layer that sits on top of all the bare Git repositories on the central server that gives the Gitolite administrator the ability to assign privileges and control what repositories can be updated and by who, only specific developers are allowed to update specific repositories. Since it is easy to create a repositories in Git, Gitolite controls what repositories belong to which developers. Who can update what. If a developer wants to move a copy of his repository to the master central repository, he has to go through Gitolite to get there. Once installed the only way to a central repository is through Gitolite.
The way Gitolite does this is by creating a bare repository of its own on the central server to keep track of authorizations, called "gitolite-admin". Since gitolite-admin is a bare repository, the only way to update it, and change user privileges, is by pushing changes to it from the gitolite-admin repository on the Gitolite Administrator's local machine. Thus there needs to be a full Git gitolite-admin repository on the administrators local machine.
Stages of the Gitolite Installation
Fortunately, Gitolite has distinct installation stages, with tests, to make sure each stage is installed correctly. It's very important that you do the stages in order. Do not jump ahead in the installation until you have completed and tested that the previous stage is working properly.
The stages you will follow are:
(1) Install the basic tools. Install Apache, Perl, and Git on your designated central server. Install Git on the Gitolite administrators local machine. Test that everything is working properly.
(2) Install the ssh connection between the central server and the Gitolite administrators local machine. This is the most critical step of the installation and where most of the problems happen.
(3) Install Gitolite on your central server. First you install Gitolite itself, then you setup the gitolite-admin bare repository.
(4) Set up the local gitolite-admin repository on your local machine.
(5) Configure and test the Gitolite installation with test repsitories.
(6) Set up GitWeb. GitWeb is a web server, like Apache, that comes with the Git install, and allows you to see the contents of your bare central repositories, on a read-only basis, in a browser window. It will be the last thing you will install.
The first step is fairly simple and should be already completed, except maybe for the Git part.
I am going to make a big assumption and assume you can install Apache, Perl, and Git without a problem on the central Linux server. The install usually involves using a Linux package installer, like yum, to install Apache, Perl, and Git. You can check Apache with a basic web page, look for the Perl version, and check Git on the server by making a test repository.
Install Git on your local machine. I like to install a WAMP stack on my local Windows machine using Wampserver for local development, and then install Git in a Msysgit Linux window. If your local machine is Windows, see my article on installing Git on Windows to do that. Check to see if you can create a local Git repository before continuing.
My next article we'll cover, the Gitolite ssh connection. This is the most important and critical step in the installation, and the one that will cause you the most problems.