Child pages
  • Gitolite (git administration)

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

Gitolite is an access control layer on top of git. Here are the features that most people see:

  • Use a single unix user ("real" user) on the server.
  • Provide access to many gitolite users:
    • they are not "real" users,
    • they do not get shell access.
  • Control access to many git repositories:
    • read access controlled at the repo level,
    • write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags.
  • Can be installed without root access, assuming git and perl are already installed.
  • Authentication is most commonly done using sshd, but you can also use http if you prefer (this may require root access).

Pre-requisites

Server

  • Any Unix system with a posix POSIX compatible "sh" and a sane file system.
  • Git version 1.6.6 or later. (Git 1.7.8 or later if you want to run the test suite).
  • Perl 5.8.8 or later.
  • Openssh (almost any version). Optional if you're using smart http.
  • A dedicated Unix userid to be user for the hosting user, usually "git" but it can be any user, even your own normal one. (If you're using an RPM/DEB the install probably created one called "gitolite").

...

TODO: which packages to install for Ubuntu 12.04 and 14.04 and Debian 6, 7 and 8?

Client

  • Openssh client.
  • Git 1.6.6 or later. Almost any git client will work, as long as it knows how to use ssh keys and send the right one along.

TODO: which packages to install for Ubuntu 12.04 and 14.04 and Debian 6, 7 and 8?

The gitolite client is an ordinary git client, documented at Git user manual

Installation

Server

Gitolite has only one server side "command" now, much like git itself. This command is gitolite. You don't need to place it anywhere special; worst case you run it with the full path.

...

When in doubt, run 'gitolite setup' anyway; it doesn't do any harm, though it may take a minute or so if you have more than a few thousand repos!

Client

TBCThe gitolite client is an ordinary git client, documented at Git user manual

Configuration and administration

Gitolite

to adminster administer gitolite just:

Code Block
git clone git:gitolite-admin

The directory tree is self explanatory

To update just commit:

Code Block
git commit -a #tell git about the changes you want to incorporate
git push # send it to the server

 

Client

Each user needs an ssh host for the git server in their $HOME/.ssh config.

In case the file does not already exist, create it with bluelight git's /"conf/ssh/Individual user/config.head":

Code Block
titleconfig.head
# User-specific ssh client configuration
# Documentation: ssh_config man page
# Default values (may be explicitly listed below for visibility):
# - Protocol 2 (important; many options are protcol-specific)
# - ServerAliveCountMax 3
Host *
    Compression yes
    Protocol 2 
    SendEnv LANG LC_*
    ServerAliveInterval 15
    ServerAliveCountMax 3

 

The ssh host stanza for the Blue Light git server is:

Code Block
title~.ssh/config
Host git
    HostName git.bluelightav.org
    Port 2222
    User git

References

Documentation

...

Set the "remote" of an "orphan", local git repo, to a new repo created with gitolite

This is a usual use case: a repo has been created on a development machine, before the repo created using gitolite on the server.

Assume you have an existing project you want to add in your new repository.

Code Block
languagebash
cd foo
git init
git add --all
git commit -m "Initial commit"

Link your local repository with your remote repository then push the local content to your remote repository.

Code Block
languagebash
git remote add origin git-bluelight:foo
git push --set-upstream origin master

References

TBC