Assumptions:
– You are familiar with:
– OS: at least one Unix-like OS
– ssh: ssh, ssh keys, ssh authorized keys file
– git: basic use of git, bare and non-bare remotes
– You are setting up a fresh, ssh-based, installation of gitolite on a Unix machine of some sort.
– You have root access.

server requirements:
– any unix system
– sh
– git 1.6.6 or later
– perl 5.8.8 or later
– openssh 5.0 or later
– a dedicated userid to host the repos (in this document, we assume it is “git”, but it can be nything; substitute accordingly)
– this user id does NOT currently have any ssh pubkey-based access
– ideally, this user id has shell access ONLY by “su – git” from some
– other userid on the same server (this ensure minimal confusion for ssh newbies!)

 Steps to installation

Server:

On server(gitserver) create new user “git” as root and set up password for it. Make sure `~/.ssh/authorized_keys` is empty or non-existent. login to “git” on the server.

[root@gitserver ~]# useradd git
[root@gitserver ~]# passwd git
Changing password for user git.
New password:
BAD PASSWORD: it is based on a dictionary word
Retype new password:
passwd: all authentication tokens updated successfully.
[root@gitserver ~]# su - git

Install git on server and client machine

# yum install git

Install gitolite on server

[root@gitserver ~]# su - git

[git@gitserver ~]$ git clone git://github.com/sitaramc/gitolite
Initialized empty Git repository in /home/git/gitolite/.git/
remote: Counting objects: 9312, done.
remote: Total 9312 (delta 0), reused 0 (delta 0), pack-reused 9312
Receiving objects: 100% (9312/9312), 2.93 MiB | 540 KiB/s, done.
Resolving deltas: 100% (5759/5759), done.

Create bin directory inside git users home directory:

[git@gitserver ~]$ mkdir -p $HOME/bin

Hit below command to run install script under gitolite directory which will create symlinks for binaries under bin directory.

[git@gitserver ~]$   gitolite/install -ln ~/bin/

On client:

Add git users on client machine as gituser1 and gituser2 :

[root@client ~]# useradd gituser1

Set password for gituser1 and gituser2

[root@client ~]# passwd gituser1
Changing password for user gituser1.
New password:
BAD PASSWORD: it is too simplistic/systematic
Retype new password:
passwd: all authentication tokens updated successfully.

Generate a ssh key for gituser1 and gituser2

[root@client ~]# su - gituser1
[gituser1@client ~]$ ssh-keygen -b 2048 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gituser1/.ssh/id_rsa):
Created directory '/home/gituser1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/gituser1/.ssh/id_rsa.
Your public key has been saved in /home/gituser1/.ssh/id_rsa.pub.
The key fingerprint is:
4d:06:41:66:c1:d6:c7:e7:8f:2a:45:51:b6:e2:2c:9b gituser1@client
The key's randomart image is:
+--[ RSA 2048]----+
| oB+ . .o |
| oo.. +... |
| . o..+. |
| + o... |
| S o.o o |
| +. . .|
| E. . |
| . . |
| . |
+-----------------+

Copy newly generated keys to gitserver. make sure your ssh public key from your workstation has been copied as
$HOME/YourName.pub

[gituser1@client ~]$ scp .ssh/id_rsa.pub git@gitserver:/home/git/gituser1.pub
The authenticity of host 'gitserver(192.168.1.10)' can't be established.
RSA key fingerprint is bc:5d:61:e4:66:75:eb:bf:cc:56:3b:d0:03:3f:0a:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.10' (RSA) to the list of known hosts.
git@192.168.1.10's password:
id_rsa.pub 100% 399 0.4KB/s 00:00
[gituser1@client ~]$

On Server:

[git@gitserver ~]$ gitolite setup -pk gituser1.pub
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/git/repositories/testing.git/
WARNING: /home/git/.ssh missing; creating a new one
 (this is normal on a brand new install)
WARNING: /home/git/.ssh/authorized_keys missing; creating a new one
 (this is normal on a brand new install)

You will see something like below:

[git@gitserver ~]$ ls
bin gitolite gituser1.pub projects.list repositories

From Client:

[gituser1@client ~]$ ssh git@gitserver info

You might see something like this:

hello gituser1, this is git@gitserver running gitolite3 v3.6.6-3-g72c0238 on git 1.7.1
R W gitolite-admin
R W testing

You should be able to clone gitloite-admin :

[gituser1@client ~]$ git clone git@gitserver:gitolite-admin

Adding git users and repositories

Do NOT add new repos or users manually on the server. Gitolite users, repos, and access rules are maintained by making changes to a special repo called “gitolite-admin” and *pushing* those changes to the server. To administer your gitolite installation, start by cloning gitolite-admin repo on your workstation .

[gituser1@client ~]$ git clone git@gitserver:gitolite-admin

NOTE: if you are asked for a password, something went wrong.  check your installation again.

Now if you “cd gitolite-admin”, you will see two subdirectories in it: “conf” and “keydir”.

To add new users gituser2, gituser3 and gituser4, obtain their public keys and add them to “keydir” as alice.pub, bob.pub, and carol.pub respectively.

To add a new repo “foo” and give different levels of access to these users, edit the file “conf/gitolite.conf” and add lines like this:

repo dev-testing
 RW+ = gituser2
 RW = gituser4
 R = gituser3

Once you have made these changes, do something like this:

git add conf
git add keydir
git commit -m "added foo, gave access to gituser2, gituser3, gituser3"
git push

When the push completes, gitolite will add the new users to `~/.ssh/authorized_keys` on the server, as well as create a new, empty, repo called “dev-testing”.

Users Testing:

Once a user has sent you their public key and you have added them as specified above and given them access, you have to tell them what URL to access their repos at. This is usually “git clone git@host:reponame”; see man git-clone for other forms.

NOTE: again, if they are asked for a password, something is wrong.
If they need to know what repos they have access to, they just have to run:

ssh git@host info

Git Access rule examples:

Gitolite’s access rules are very powerful. The simplest use was already shown above. Here is a slightly more detailed example:

repo dev-testing
 RW+ = gituser2
 - master = gituser3
 - refs/tags/v[0-9] = gituser3
 RW = gituser3
 RW refs/tags/v[0-9] = gituser4
 R = gituser5

Here’s what these example rules say:

– gituser2 can do anything to any branch or tag — create, push, delete, rewind/overwrite etc.

– gituser3 can create or fast-forward push any branch whose name does not start with “master” and create any tag whose name does not start with “v”+digit.

– gituser4 can create tags whose names start with “v”+digit.

– gituser5 can clone/fetch.

groups

Gitolite allows you to group users or repos for convenience. Here’s an example that creates two groups of users:

@staff = gituser1 gituser2 gituser3
 @interns = gittestuser1

repo dev-testing
 RW = @staff

repo foss
 RW+ = @staff
 RW = @interns

Group lists accumulate. The following two lines have the same effect as the earlier definition of @staff above:

@staff = gituser1 gituser2
@staff = gituser3

You can also use group names in other group names:

@all-devs = @staff @interns

Finally, @all is a special group name that is often convenient to use if you really mean “all repos” or “all users”.

Users can run certain commands remotely, using ssh. Running

ssh git@host help

prints a list of available commands.

The most commonly used command is “info”. All commands respond to a single argument of “-h” with suitable information.

If you have shell on the server, you have a lot more commands available to you; try running “gitolite help”.

references:  http://gitolite.com