IMPORTANT: This guide is for the old 2.x version of gitolite, which is(as of April 22nd 2012) the one found in most OS package repositories. Please consider using the current 3.x branch of gitolite, for which a very nice howto is written by the author.
This is a quick walkthrough on how to install and begin using gitolite in under a minute(only 4 commands!). Just follow along through the shell blocks. Reading the gitolite docs is STRONGLY recommended.
- Operating System:
- CentOS/Scientific Linux 6 with the EPEL yum repo configured
- Ubuntu 10.10 or higher
- General familiarity with the shell
- Existing SSH public-keys(rsa or dsa)
- sudo access
CentOS/Scientific Linux:
[user@hostname ~]$ sudo yum install gitolite -y
(NOTE: output trimmed for brevity]
Installed:
gitolite.noarch 0:2.0.3-2.el6
[user@hostname ~]$
Ubuntu:
[user@hostname ~]$ sudo apt-get install gitolite
(NOTE: output trimmed for brevity)
The following NEW packages will be installed:
gitolite
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
[user@hostname ~]$
Gitolite is now installed, but is not ready for use. You will need to copy your SSH public key to somewhere gitolite can access it, and then run the setup script.
[user@hostname ~]$ cp .ssh/id_rsa.pub /tmp/user.pub
[user@hostname ~]$ sudo su - gitolite
-sh-4.1$ gl-setup -q /tmp/user.pub
creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /var/lib/gitolite/repositories/testing.git/
[master (root-commit) adee3f7] start
2 files changed, 6 insertions(+), 0 deletions(-)
create mode 100644 conf/gitolite.conf
create mode 100644 keydir/user.pub
-sh-4.1$ exit
logout
[user@hostname ~]$
I cheated a bit when I said "only 4 commands!" above, because I stopped counting at gl-setup. Technically speaking, gitolite is usable at this stage, but configuration is needed to do anything useful. Never mind that, let's go ahead and use it!
Start by seeing what repositories gitolite will let us access, using the info command:
[user@hostname ~]$ ssh gitolite@localhost info
hello user, this is gitolite v2.1-29-g5a125fa running on git 1.7.1
the gitolite config gives you the following access:
R W gitolite-admin
@R_ @W_ testing
The output is fairly self-explanatory, but please read the documentation on it. The setup process gave us two repositories: gitolite-admin, which gitolite uses to control access, and testing, which is provided to let you play around. So, do that!
[user@hostname ~]$ git clone gitolite@localhost:testing.git
Initialized empty Git repository in /home/user/testing/.git/
warning: You appear to have cloned an empty repository.
[user@hostname ~]$ cd testing/
[user@hostname testing]$ ls -a
. .. .git
[user@hostname testing]$ git log
fatal: bad default revision 'HEAD'
[user@hostname testing]$
Because this repository was just created, there is nothing in it. So, put something there!
[user@hostname testing]$ echo "This is a README file" > README.txt
[user@hostname testing]$ git add README.txt
[user@hostname testing]$ git commit -m 'Initial commit of testing repository'
[master (root-commit) f3a9a57] Initial commit of testing repository
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README.txt
[user@hostname testing]$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 257 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To gitolite@localhost:testing.git
* [new branch] master -> master
[user@hostname testing]$
It doesn't make much sense to use a repository named 'testing' for everything, so you should create some new ones.
Gitolite keeps all repository & user public-key information inside of a git repository, helpfully named gitolite-admin.git. So, clone it and have a look-see:
[user@hostname testing]$ cd ..
[user@hostname ~]$ git clone gitolite@localhost:gitolite-admin.git
Initialized empty Git repository in /home/user/gitolite-admin/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
[user@hostname ~]$ cd gitolite-admin/
[user@hostname gitolite-admin]$ ls -a
. .. conf .git keydir
[user@hostname gitolite-admin]$ ls conf/
gitolite.conf
[user@hostname gitolite-admin]$ cat conf/gitolite.conf
repo gitolite-admin
RW+ = user
repo testing
RW+ = @all
[user@hostname gitolite-admin]$ ls keydir/
user.pub
[user@hostname gitolite-admin]$
As you can see, repositories are defined in conf/gitolite.conf(syntax overview), and user keys go into keydir/. Add some new repositories to your config file, and then commit+push your changes
[user@hostname gitolite-admin]$ cat conf/gitolite.conf
repo gitolite-admin
RW+ = user
repo testing
RW+ = @all
repo website
RW+ = user
[user@hostname gitolite-admin]$ git add conf/gitolite.conf
[user@hostname gitolite-admin]$ git commit -m "Add a repo for user's website"
[master 7c22283] Add a repo for user's website
1 files changed, 3 insertions(+), 0 deletions(-)
[user@hostname gitolite-admin]$ git push
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 390 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: creating website...
remote: Initialized empty Git repository in /var/lib/gitolite/repositories/website.git/
To gitolite@localhost:gitolite-admin.git
07baef8..7c22283 master -> master
[user@hostname gitolite-admin]$
And verify that the changes worked:
[user@hostname gitolite-admin]$ ssh gitolite@localhost info
hello user, this is gitolite v2.1-29-g5a125fa running on git 1.7.1
the gitolite config gives you the following access:
R W gitolite-admin
@R_ @W_ testing
R W website
[user@hostname gitolite-admin]$
When you push the gitolite-admin repository, gitolite automagically initializes any new repositories. You can now clone+use website just like you did testing.
Congratulations, you have a working gitolite instance! Enjoy! And read the documentation.