GitoLite: Unterschied zwischen den Versionen

Aus Info-Theke
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „Kategorie:ServerSoftware ==Vorbemerkung== '''gitolite''' ist ein Verwaltungssystem für GIT-Repositories. gitolite bietet den Vorteil, dass die Benutzerverw…“)
 
Zeile 1: Zeile 1:
[[Kategorie:ServerSoftware]]
[[Kategorie:ServerApplikation]]


==Vorbemerkung==
==Vorbemerkung==

Version vom 6. März 2012, 10:10 Uhr


Vorbemerkung

gitolite ist ein Verwaltungssystem für GIT-Repositories.

gitolite bietet den Vorteil, dass die Benutzerverwaltung der Repositories von der Benutzerverwaltung des Servers getrennt wird.

Der Zugriff auf die Repositories erfolgt verschlüsselt. Die Schlüsselverwaltung übernimmt gitolite.

Installation

 apt-get install gitolite

gitolite setzt GIT Version 1.7 voraus. Das gibt es für Debian Lenny im Backport-Repository.

gitolite verwaltet sich selbst in einem GIT-Repository. Die Server-Konfigration wird also lokal geändert und dann auf den Server geladen. Wir verschaffen uns Zugang zum Server:

 # Auf dem lokalen Host:
 REMOTE_HOST=f-r-e-i.de
 USER=jonny
 cd ~/.ssh
 scp id_dsa.pub $REMOTE_HOST:/tmp/$USER.pub

Es geht auf dem Server weiter:

 # Auf dem Server:
 adduser git
 su git
 cd $HOME
 git clone git://github.com/sitaramc/gitolite
 cd gitolite
 src/gl-system-install
 gl-setup ~/YourName.pub

Jetzt holen wir das gitosis-Verwaltungsrepository lokal:

 # Auf dem lokalen Host:
 DIR=~/gitadmin
 mkdir $DIR ; cd $DIR
 git clone git@server:gitolite-admin

User eintragen

Der Benutzer jonny soll Zugang bekommen. Der öffentliche Schlüssel liegt als Datei /tmp/jonny.pub vor:

 # Lokal:
 DIR=~/gitadmin
 USER=jonny
 cd $DIR/gitolite-admin
 cp /tmp/$USER.pub keyfiles
 # Die Änderungen ins lokale Repository übernehmen:
 git add keydir/$USER.pub
 git commit -m "Neuer User $USER" keydir/$USER.pub
 # Und ab auf den Server...
 git push

Als Zeichen sind Buchstaben, Ziffern, '_' und '.' zulässig. Zusätzlich ist die Syntax von "echten" EMailadressen möglich, wenn also nach dem '@' eine Buchstabenfolge, dann ein '.' und wieder Buchstaben vorkommen.

Neues Repository einrichten

 # Auf dem lokalen Host:
 DIR=~/gitadmin
 cd $DIR/gitolite-admin
 $EDITOR conf/gitolite.conf

Nach diesem Muster eintragen:

# Gruppe tutor mit 3 Mitgliedern:
@tutor = hm republ
# @all sind immer alle bekannten Benutzer
repo    git-tut-example-01
        RW+C = @tutor
        R    = @all

Nach der Änderung committen und ab zum Server:

 git add conf/gitolite.conf
 git commit -m "Neues Repo: git-tut-example-01" conf/gitolite.conf
 git push

Nach dem Push wird auf dem Server in leeres Repository angelegt. Die zugelassenen Benutzer können dann so das Repository clonen:

 git clone gitolite@f-r-e-i.de:git-tut-example-01

Repositories können in Unterverzeichnissen angelegt werden:

repo    public/example-repo
 R = @all

Zugriff dann mit:

 git clone gitolite@server:public/example-repo

Viele Repositories verwalten

Siduction benötigt viele Repositories. Dies wird erleichtert, indem Einzelbereiche in eigene Konfigurationsdateien ausgelagert werden können. Diese werden dann mit der "include"-Anweisung in andere Konfigiurationsdateien (z.B. gitolite.conf) eingebunden:

# Beispiel fuer eine gitolite.conf:
@admin = hm

include "republib.conf"
include "hama.conf"
include "tools.conf"
include "others.conf"

Vorhandenes Repository exportieren

Als Beispiel dient das neue Repository reportal.

  • Eintrag in die Konfiguration von gitolite
  • Beim Push wird ein leeres Repository reportal.git auf dem Server angelegt.
  • Entferntes Repository in die GIT-Konfiguration von reportal eintragen:

reportal/.git/config

...
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = gitolite@f-r-e-i.de:republib/java/reportal
...