GitoLite: Unterschied zwischen den Versionen
Zeile 124: | Zeile 124: | ||
url = gitolite@f-r-e-i.de:republib/java/reportal | url = gitolite@f-r-e-i.de:republib/java/reportal | ||
... | ... | ||
</pre> | |||
=== Leeres Depot füllen === | |||
<pre> | |||
git push origin master | |||
</pre> | </pre> |
Version vom 6. März 2012, 10:48 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 ...
Leeres Depot füllen
git push origin master