HOWTO: Gitweb für Gitosis, oder wie der Git Server sichtbar wird

Nachdem ich hier erst letztens aufgezeigt habe wie man seinen eigenen Git Server mithilfe von Gitosis aufsetzt, möchte ich heute noch etwas tiefer in die Materie vordingen. Heute soll der Git Server visualisiert werden mithilfe von Gitweb.

Nachdem ich hier erst letztens aufgezeigt habe wie man seinen eigenen Git Server mithilfe von Gitosis aufsetzt, möchte ich heute noch etwas tiefer in die Materie vordingen. Heute soll der Git Server visualisiert werden mithilfe von Gitweb.

Gitweb

Im Prinzip ist Gitweb recht flott installiert wenn man auf die Paketverwaltung der Distribution seines Vertrauens setzt. In meinem Beispielfall ist das Debian und mittels

$ aptitude install gitweb

wird die Software installiert. Damit Gitweb auf die eigenen Repositories zugreifen kann muss natürlich die Konfiguration /etc/gitweb.conf angepasst werden:

# path to git projects (.git) - hier auf das bei der installation von gitosis eventuell angepasste Verzeichnis linken
$projectroot = “/home/git/repositories/”;

# directory to use for temp files
$git_temp = “/tmp”;

# target of the home link on top of all pages
#$home_link = $my_uri || “/”;

# html text to include at home page
$home_text = “indextext.html”;

# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;

# Point to projects.list file generated by gitosis. - Hier ist wieder ein anpassung erforderlich wenn das homeverzeichnis wie bei unserem Beispiel angepasst wurde
$projects_list = “/home/git/gitosis/projects.list”;

# stylesheet to use
$stylesheet = “/gitweb.css”;

# javascrip code for gitweb
$javascript = "gitweb.js";

# logo to use
$logo = “/git-logo.png”;

# the ‘favicon’
$favicon = “/git-favicon.png”;

# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = (’git://git.host.example’);

#$strict_export = “true”;

$projectroot – der Pfad zu den von gitosis erzeugten Repositories, in unserem fall /home/git/repositories;
$projects_list – damit wird gitweb gezeigt welche Repos vorhanden sind, entweder indem man auf das root Verzeichnis verweist oder auf eine Datei die eine Liste der Repositories beinhaltet. Verweist man auf die von gitosis erzeugte Projektliste “/home/git/gitosis/projects.list”; kann man über die Konfiguration von gitosis gezielt steuern, welche Repos angezeigt werden sollen.
Projekte die nicht angezeigt werden können mit obiger Konfiguration trotzdem noch durch direkten Aufruf über die Adressliste des Browsers erreicht werden. Soll auch dieser Aufruf unterbunden werden muss man den strict_export parameter auf true setzen, einfach dazu das Kommentarzeichen entfernen.

Nun muss noch im Webserver, in meinem Falle Apache2, richtig konfiguriert werden. Dazu habe ich eine eigene virtuelle Domain eingepflegt in folgender Datei /etc/apache2/sites-available/gitweb:

<VirtualHost *:80>
    ServerAdmin john@example.com
    DocumentRoot /var/cache/git
    ServerName git.example.com
    Alias /gitweb.css /usr/share/gitweb/gitweb.css
    Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
    Alias /git-logo.png /usr/share/gitweb/git-logo.png
    ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>

Abschließend muss noch der Benutzer des Webservers www-data der gitosis gruppe hinzugefügt werden, damit der lesende Zugriff erfolgen kann. Danach wird die neu erstellte Subdomain noch aktiviert

$ a2ensite gitweb

Und Apache neu gestartet

$ /etc/init.d/apache2 reload

Wer cgi noch enabeln muss sollte danach nicht vergessen Apache ganz neu zu starten

$ /etc/init.d/apache2 restart

Und schon sollte der eigene Gitweb Zugriff fertig aufgesetzt sein.

Gitweb in der Gitosisconf

Fehlt natürlich noch die Konfiguration der Repositories um einzelne Projekte in Gitweb auszublenden

Im allgemeinen Bereich definiert hier der vorsichtige User folgendes:

[gitosis]
daemon = no
gitweb = no

Damit schließt man prinzipiell alle Projekte von der Ansicht in Gitweb aus. So wechselt man von einem Opt-Out Verfahren bei dem bei jedem Repo angegeben hätte werden müssen dass es nicht angezeigt werden soll, zu einem Opt-In, bei dem man sich bewusst für das anzeigen in Gitweb entscheiden muss.

Will man nun zB das Repository test in Github angeboten bekommen ist folgender Eintrag notwendig:

[repo test]
description = A repository where tests can take place
owner = testuser
daemon = no
gitweb = yes

Viel Spaß mit Git im Web!

Ähnliche Artikel:

HOWTO: Gitdaemon für den eigenen Gitserver

Will man seinen Gitosis – Gitserver etwas öffentlicher gestalten und der Allgemeinheit lesenden Zugriff auf seine Repositories gewähren will, dem steht das git Protokoll zur Auswahl. Der entsprechende Daemon ist unter Debian denkbar leicht zu installieren

Will man seinen Gitosis – Gitserver etwas öffentlicher gestalten und der Allgemeinheit lesenden Zugriff auf seine Repositories gewähren will, dem steht das git Protokoll zur Auswahl. Der entsprechende Daemon ist unter Debian denkbar leicht zu installieren

$ aptitude install git-daemon-run

Der Git Daemon verwendet jedoch nicht die üblichen /etc/init.de/ Runscripte sondern nutzt runit/runsv. Ein entsprechender Symlink hilft da alten Gewohnheiten schnell mal auf die Sprünge:

$ ln -s /usr/bin/sv /etc/init.d/git-daemon

Abschließend noch die Konfiguration /etc/sv/git-daemon/run an die Pfade von Gitosis angepasst (Hier als Beispiel mit dem angepassten Home Verzeichnis aus dem dazugehörigen Gitosis Tutorial):

#!/bin/sh
exec 2>&1
echo ‘git-daemon starting.’
exec chpst -ugitdaemon "$(git --exec-path)"/git-daemon --verbose --reuseaddr --base-path=/home/git/repositories /home/git/repositories

–reuseaddr ermöglicht es dem gitserver neu zustarten ohne auf bestehende Verbindungen rücksicht nehmen zu müssen und auf ein Timeout warten zu müssen.

Und schon steht dem giten über das eigene Protokoll nichts mehr im Wege. Außer vielleicht die Firewall, da brauchts ein extra Löcherl auf Port 9418.

Gitosis

In Gitosis gilt es nun noch den Git Daemon zu konfigurieren:
Der allgemeine Teil erhält ein generelles Opt-Out:

[gitosis]
daemon = no

Einzelne Repositories werden dann aktiv geschalten:

[repo test]
description = A repository where tests can take place
owner = testuser
daemon = yes

git://git.example.org/gutes_gelingen.git

Ähnliche Artikel:

Builder Pattern

Das Builder Pattern erleichtert das Erstellen von Objekten mit vielen Variablen, Pflichtfelder und Optionalen Felder. Auch kann dadurch sichergestellt werden, dass immutable Objekte erstellt werden wenn benötigt. Wie das funktioniert möchte ich in diesem Artikel erläutern.

Ich möchte heute das Builder Pattern vorstellen. Dieses Pattern erleichtert das Erzeugen von Objekten mit einer Vielzahl von Variablen. Anstatt für verschiedene gesetzte Variablen unterschiedliche Konstruktoren mit einer großen Menge an Parametern zu schreiben nutzt man den Ansatz der Verkettung. Mittels einer statischen inneren Klasse regelt man die Erzeugung einer Instanz der äußern Klasse.

Diese innere Klasse, der Builder, enthält Pflichtvariablen die über den Konstruktor der inneren Klasse gesetzt werden. Optionale Variablen, versehen mit Default-Werten, werden über verkettete Methodenaufrufe befüllt. Verkettet bedeutet dass die Methode jeweils das Objekt auf dem es aufgerufen wird zurückgibt. Abschließend wird die build() Methode aufgerufen. Diese returniert ein Objekt der äußeren Klasse, indem es dem Konstruktor der außeren Klasse eine Referenz auf sich selbst übergibt.

Möchte man ein unveränderliches Objekt der äußeren Klasse erzeugen, deklariert man den Konstruktor der äußeren Klasse privat und bietet keine setter Methoden. Die Variablen werden außerdem final gesetzt. Somit hat man ein immutable Objekt. Dadurch kann nur die innere Klasse, der Builder, eine Instanz des Objekts erzeugen und verändern.

public class ObjectToCreate {
	private final String a;
	private final int b;
	private final int c;
	private final String d;
	private final boolean e;
	private final int f;

	private ObjectToCreate(Builder builder) {
		// private Constructor can only be called from Builder
		this.a = builder.a;
		this.b = builder.b;
		this.c = builder.c;
		this.d = builder.d;
		this.e = builder.e;
		this.f = builder.f;
	}

	public String getA() {
		return a;
	}

	public int getB() {
		return b;
	}

	public int getC() {
		return c;
	}

	public String getD() {
		return d;
	}

	public boolean isE() {
		return e;
	}

	public int getF() {
		return f;
	}

	public static class Builder {
		// Pflichtfelder
		private final String a;
		private final int b;
		// Optional
		private int c = 0;
		private String d = "default";
		private boolean e = true;
		private int f = 0;

		public Builder(String a, int b) {
			this.a = a;
			this.b = b;
		}

		public Builder c(int c) {
			this.c = c;
			return this;
		}

		public Builder d(String d) {
			this.d = d;
			return this;
		}

		public Builder e(boolean e) {
			this.e = e;
			return this;
		}

		public Builder f(int f) {
			this.f = f;
			return this;
		}

		public ObjectToCreate build() {
			return new ObjectToCreate(this);
		}
	}
}

Das wollen wir natürlich auch noch testen

public class ObjectToCreateTest {
	public static void main(String... args) {
		ObjectToCreate.Builder builder = new ObjectToCreate.Builder("String", 1);
		ObjectToCreate o = builder.c(2).d("uiuiui").e(false).f(3).build();
	}
}

Happy building!

Ähnliche Artikel:

  • Noch keine vorhanden.

HOWTO: Git Commands – ein Überblick

Ein Überblick über die wichtigsten Kommandos in Git zur Versionsverwaltung. Branchen, Taggen, an den Server senden. Alles ist abgedeckt

Von Git hab ich hier ja schon ein paar mal geschrieben. Gestern war dann sogar ein Howto für den eigenen Git Server an der Reihe. Damit wir nun auch damit arbeiten können möchte ich hier kurz und knackig die wichtigsten Git Befehle anführen:

Allgemein

Um ein komplett neues Projekt lokal anzulegen, erst das Verzeichnis anlegen, dann in das Verzeichnis wechseln und abschließent Git initialisieren

$ git init

Um das Repository auszuchecken

$ git clone gitosis@example.com:repository.git

Um zu sehen was sich lokal getan hat und noch nicht commited wurde

$ git status

Um Änderungen lokal zu commiten

$ git commit -am „Commit Description“

Das Git log ansehen

$ git log
$ git log –pretty=oneline
$ git log –date=short –pretty=format:“%ad: %s“ –since=“4 month ago“

Um zu sehen was sich am Server getan hat

$ git log –no-merges origin/master

Um den eigenen Datenbestand mit den letzten Änderungen vom Server abzugleichen:

$ git fetch origin
$ git merge origin/master

$ git pull origin master

Um seine Änderungen auf den Server zu laden in den Master-branch

$ git push origin master

Branches

Einen Branch anlegen oder zu ihm wechseln

$ git checkout -b branchname

Auf einen Branch wechseln (Legt keinen neuen an wenn nicht vorhanden)

$ git checkout branchname

Einen Branch auf den Server laden

$ git push origin branch

Einen Branch mit dem aktuell ausgecheckten Branch mergen

$ git merge branchname

Einen Branch lokal löschen

git branch -d branchname

Einen Branch am Server löschen

$ git push origin :branchname

Tags

Einen Tag anlegen

$ git tag -a tagname -m „tag description“

Einen Tag zum Server schicken

$ git push origin tag tagname

Alle Tags zum Server schicken

$ git push origin –tags

Einen Tag löschen

$ git tag -d tagname

Einen Tag am Server löschen

$ git push origin :tagname

Commitverwaltung

Ein Commit zurücknehmen

$ git reset –hard HEAD^

Mehrere Commits zurücknehmen (zB 3)

$ git reset –hard HEAD^^^
$ git reset –hard HEAD~3

Patch für Server erzeugen

$ git format-patch origin/master

Patchfiles für letzten 3 Commits erzeugen

$ git format-patch HEAD^^^

Patchfile einspielen

$ git am < patchfile

Was vergessen? Ab in die Kommentare damit. Viel Erfolg beim Versionsverwalten!

Eine gute Quelle für den Einstieg in Git ist unter anderem: http://de.gitready.com/

Ähnliche Artikel:

HOWTO: Der eigene GIT Server mit Gitosis

Eine Versionsverwaltung gibt Stabilität, Kontrolle und vereinfacht die Arbeit im Team. Deshalb wird hier erklärt wie man seinen eigenen Git Server aufsetzt und konfiguriert.

Ich hab ja unlängst über die Vorzüge von Source Control Management Lösungen gesprochen. Deshalb möchte ich nun aufzeigen wie man sich selbst eine entsprechende Versionsverwaltung aufsetzt. Wir werden einen GIT Server aufsetzen und somit auf den Trend den Github und Co vorlebten aufspringen. Um eine einfache Verwaltung für den Zugriff von mehreren Usern auf verschiedene Repositories zu ermöglichen verwenden wir Gitosis

In diesem Tutorial setzen wir Gitosis auf dem neuesten Debian Squeeze Release, Version 6.0.3, auf. Dazu wurde das Betriebssystem in einer Virtual Machine aufgesetzt.

Zu erst installieren wir Git, den Kern unseres Tutorials:

# aptitude install git-core

Danach wird mit der Installation von Gitosis fortgefahren. Dabei könnten, so noch nicht installiert, diverse Abhängigkeiten zu Python installiert werden. Außerdem wird ein User mit dem Namen Gitosis, ebenso wie eine namensgleiche Gruppe und unter /srv/gitosis ein Homeverzeichnis für den User angelegt.

# aptitude install gitosis

Nach der Installation benötigt man einen ssh-rsa Key um sich als Administrator zu registrieren. Diesen benötigt man auf der Client Seite. Unter Windows ist dieser zB mit Puttygen zu erzeugen. Unter Linux wäre der Befehl:

ssh-keygen –t rsa –C “john@example.com

Dieser funktioniert auch in der Git Bash so man unter Windows auf msysgit zurückgreift.

Dabei werden 2 Files erzeugt: id_rsa (Private Key) und id_rsa.pub (Public Key).

Der Public Key wird nun auf den Linux Server transferiert, der Private Key bleibt nur am Client. Der Transfer kann mittels scp oder wget durchgeführt werden. Abgelegt sollte er unter dem Benutzernamen mit dem man am Server unterwegs ist in folgendes Verzeichnis: /etc/gitosis/sshkeys z.B. /etc/gitosis/sshkeys/theuser

Nicht vergessen darf man, dass man dem gitosis User alle notwendigen Rechte auf den Key verpasst:

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Möchte man das Homeverzeichnis des gitosis Users an einen anderen Ort legen kann man das wie folgt:

# mkdir /home/git

# usermod -d /home/git gitosis

Nicht vergessen rechte geben!

# chown -R gitosis:gitosis /home/git

Nun sind wir soweit, das Admin Repository kann angelegt werden. Gitosis verwendet nämlich ein eigenes Git Repository in dem alle Daten zur Erzeugung der individuellen Repositories und zur Steuerung der Rechte auf diese hinterlegt werden. Dazu wechseln wir auf den gitosis User

# su gitosis

und initialisieren dann den Dienst

$ gitosis-init < /etc/gitosis/sshkeys/thefake

Dabei müssten zwei Zeilen ausgegeben werden die in etwa so aussehen:

Initialized empty Git …
Reinitialized existing Git …

Hat der Server den SSH Port nicht wie standardmäßig auf Port 22 sondern z.B. auf 22222, muss am Client selbst unter ~/.ssh ein File mit dem Namen config angelegt werden. Dort trägt man dann den Host sowie den Port auf dem SSH zu finden ist ein:

Host 10.0.0.3
Port 22022

Nun steht dem initialen Auschecken des Admin-Repositories nichts mehr im Wege. Wir wechseln deshalb auf den Client, auf dem wir Git bereits installiert haben und holen uns das Repository folgendermaßen:

$ git clone gitosis@10.0.0.3:gitosis-admin.git

Dabei erhält man eine lokale Kopie der Configuratinsdatei sowie des Schlüsselverzeichnisses.

Um nun ein neues Repository anzulegen editiert man das Configurationsfile gitosis.conf mit einem Editor seiner Wahl und ergänzt es um folgende Zeilen

[group projektname]
writable = projektname
members = user@example.com

group benennt eine Gruppe von Usern, über die Kindattribute writable und members werden deren Rechte sowie deren Identitäten festgelegt. So kann im obigen Beispiel der Benutzer user@example.com auf das Projekt projektname zugreifen. Mittels Leerzeichen kann man hier mehrere User oder Repositories angeben. Mehr dazu später oder auf in der Gitosis Dokumentation zur Configurationsdatei.

Der Benutzer user@example.com benötigt einen public ssh-rsa Key der im Administrations-Projekt im Unterverzeichnis keydir hinterlegt werden muss. Dabei gilt die Namenskonvention <gitemailadresse>.pub

Erst commiten wir die neue Configuration ins lokale Repository

$ git commit -a -m „Added new repository ‚projektname'“

Anschließend wird die Configration auf den Server aufgespielt.

$ git push

Und schon können wir ein neues Projekt beginnen. Dazu erstellen wir ein neues Verzeichnis, initialisieren darin ein Git Projekt und legen eine erste Datei an.

mkdir projektname
cd projektname
git init
echo „This is a test file.“ > README
git add README

Nachdem wir das lokale Repository mit dem eben konfiguriertem Remote Repository verbunden haben commiten wir unsere lokalen Änderungen und laden diese auf den Server.

git remote add origin gitosis@10.0.0.3:projektname
git commit -a -m „Initial commit“
git push –all

Will man weitere Benutzer hinzufügen muss man deren Public Key wie vorhin beschrieben im Administrationsprojekt ablegen und fügt die Email Adresse in der Konfiguration einfach per Leerzeichen hinzu:

[group projektname]
writable = projektname
members = user@example.com another@example.com

Das ganze wird wieder commited und auf den Server gepushed, und schon ist der neue Benutzer berechtigt auf das Repo zuzugreifen.

Möchte man allgemeine Leserechte in einem Repository vergeben, ohne dass dazu ein User eingetragen werden muss, kann man dies individuell steuern indem man eine Kontrolldatei anlegt:

sudo touch /home/git/repositories/test.git/git-daemon-export-ok

Und fertig ist der Git Server. In einem weiteren Blogeintrag werde ich noch über die Installation einer Webmaske berichten. Also schaut mal wieder vorbei.

——–

Achja, sollte man noch nicht so fit mit Git selbst sein kann ich hier ein paar gute Links empfehlen:

Setting up Git (for Github)http://help.github.com/win-set-up-git/ Eine Installationsaleitung für Git unter WIndows. Die darin enthaltenen Informationen bezüglich User und User Email möchte ich nochmal hervorheben:

$ git config –global user.name “Firstname Lastname”

Damit setzt man den Namen seines Benutzers für alle Git Instanzen auf dem System

$ git config –global user.email „your_email@youremail.com

Dieser Befehl setzt die Email mit der auch über Gitosis der Key gematched wird. Sie dient somit als zentrales Element der Identifikation.

Generell sind die Github Manpages recht gute Quellen um sich mit Git vertraut zu machen.

Git Tutorials bei Kernel.org – http://web.archive.org/web/20110613161039/http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Leider derzeit offline, aber in meinen Augen der beste Überblick über die Befehle von Git, über die WayBackMachine noch erreichbar.

Wer sich vertiefend mit dem Thema auseinandersetzen will dem sein zwei Online Bücher ans Herz gelegt:

Git In The Trencheshttp://cbx33.github.com/gitt/ bzw der Source vom Buch auf Github https://github.com/cbx33/gitt

ProGithttp://progit.org/book/

Bis zum nächsten Commit!

Ähnliche Artikel: