-
1. Los geht's
- 1.1 Wozu Versionskontrolle?
- 1.2 Die Geschichte von Git
- 1.3 Git Grundlagen
- 1.4 Git installieren
- 1.5 Git konfigurieren
- 1.6 Hilfe finden
- 1.7 Zusammenfassung
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Was ist ein Branch?
- 3.2 Einfaches Branching und Merging
- 3.3 Branch Management
- 3.4 Branching Workflows
- 3.5 Externe Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einen Server bekommen
- 4.3 Generiere deinen öffentlichen SSH-Schlüssel
- 4.4 Einrichten des Servers
- 4.5 Öffentlicher Zugang
- 4.6 GitWeb
- 4.7 Gitosis
- 4.8 Gitolite
- 4.9 Git Daemon
- 4.10 Git Hosting
- 4.11 Einrichten eines Benutzeraccounts
- 4.12 Zusammenfassung
-
5. Distribuierte Arbeit mit Git (xxx)
-
6. Git Tools
- 6.1 Revision Auswahl
- 6.2 Interaktives Stagen
- 6.3 Stashing
- 6.4 Änderungshistorie verändern
- 6.5 Mit Hilfe von Git debuggen
- 6.6 Submodule
- 6.7 Subtree Merging
- 6.8 Zusammenfassung
-
7. Git individuell einrichten
-
8. Git und andere Versionsverwaltungen
- 8.1 Git und Subversion
- 8.2 Zu Git umziehen
- 8.3 Zusammenfassung
-
9. Git Internas
- 9.1 Plumbing und Porcelain
- 9.2 Git Objekte
- 9.3 Git Referenzen
- 9.4 Pack-Dateien
- 9.5 Die Refspec
- 9.6 Transfer Protokolle
- 9.7 Wartung und Datenwiederherstellung
- 9.8 Zusammenfassung
4.5 Git auf dem Server - Öffentlicher Zugang
Öffentlicher Zugang
Was ist, wenn Du anonymen Lese-Zugriff zu Deinem Projekt ermöglichen möchtest? Vielleicht möchtest Du ein Open-Source Projekt, anstatt einem privaten, nicht öffentlichen Projekt hosten. Oder Du hast ein paar automatisierte Build-Server oder Continuous Integration Server, die ständig wechseln, und Du möchtest für diese nicht dauernd neue SSH-Schlüssel generieren. Dann wäre es doch schön, wenn ein anonymer Lese-Zugriff zu Deinem Projekt möglich wäre.
Der wahrscheinlich einfachste Weg für kleinere Konfigurationen ist, einen Webserver, in dessen Basisverzeichnis die Git Repositorys liegen, laufen zu lassen und den post-update Hook, den wir im ersten Abschnitt dieses Kapitels erwähnt haben, zu aktivieren. Gehen wir vom vorherigen Beispiel aus. Sagen wir, Du hast deine Repositorys im Verzeichnis /opt/git und ein Apache-Server läuft auf Deiner Maschine. Du kannst dafür jeden beliebigen Webserver benutzen, aber in diesem Beispiel demonstrieren wir das Ganze an Hand einer Apache Basis-Konfiguration. Dies sollte Dir eine Vorstellung geben, wie Du es mit dem Webserver Deiner Wahl umsetzen kannst.
Zuerst musst Du den Hook aktivieren:
$ cd project.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
Wenn Du eine ältere Git Version als 1.6 benutzt, brauchst Du den mv-Befehl nicht auszuführen. Das Namensschema mit der .sample Endung wurde erst bei den neueren Git Versionen eingeführt.
Welche Aufgabe hat der post-update Hook? Er enthält in etwa folgendes:
$ cat .git/hooks/post-update
#!/bin/sh
exec git-update-server-info
Wenn Du via SSH etwas auf den Server hochlädst, wird Git den Befehl git-update-server-info ausführen. Dieser Befehl aktualisiert alle Dateien, die benötigt werden, damit das Repository über HTTP geholt (fetch) beziehungsweise geklont werden kann.
Als nächstes musst Du einen VirtualHost Eintrag zu Deiner Apache-Konfiguration hinzufügen. Das dort angegebene DocumentRoot Verzeichnis muss mit dem Basisverzeichnis Deiner Git Projekte übereinstimmen. In diesem Beispiel gehen wir davon aus, dass ein Wildcard-DNS Eintrag besteht, der dafür sorgt, dass *.gitserver auf den Server zeigt, auf dem das Ganze hier läuft:
<VirtualHost *:80>
ServerName git.gitserver
DocumentRoot /opt/git
<Directory /opt/git/>
Order allow, deny
allow from all
</Directory>
</VirtualHost>
Da die Apache-Instanz, die das CGI-Skript ausführt, standardmäßig unter dem Benutzer www-data läuft, musst Du auch die Unix Eigentümer-Gruppe des Verzeichnisses /opt/git auf www-data setzen. Ansonsten kann Dein Webserver die Repositorys nicht lesen:
$ chgrp -R www-data /opt/git
Nach einem Neustart des Apache, solltest Du in der Lage sein, Deine Repositorys innerhalb diesem Verzeichnis zu klonen, indem Du die URL für das jeweilige Projekt angibst.
$ git clone http://git.gitserver/project.git
Auf diese Art und Weise kannst du in wenigen Minuten einen HTTP-basierten Lese-Zugriff auf all Deine Projekte für eine große Anzahl von Benutzern ermöglichen. Ein Git Daemon ist eine andere einfache Möglichkeit für einen öffentlichen Zugang. Wenn Du diese Methode bevorzugst, solltest Du dir den nächsten Abschnitt unbedingt anschauen.