Listing 2
$ cd $ mkdir projekt $ cd projekt $ echo "Das ist mein Projekt." > info.txt $ git init $ git add info.txt $ git commit -m "Erster Commit" $ git log
Ein Git-Server hostet typischerweise nur Bare-Repos. Ein Bare-Repo, also ein nacktes oder bloßes Repo, besitzt im Gegensatz zu einem normalen Repo kein Arbeitsverzeichnis – auf dem Server wäre das auch sinnlos.
Zum Initialisieren des Repos auf dem Server gibt es zwei grundlegende Varianten und einige Mischformen. Bei Variante 1 erstellen Sie aus dem lokal vorhandenen Repo ein Bare-Repo und kopieren es auf den Server, beispielsweise per Scp. Anschließend klonen Sie vom Git-Server das Projekt in ein neues Verzeichnis auf den lokalen Rechner; alternativ benennen Sie das ursprüngliche Projektverzeichnis um. Es empfiehlt sich, das ursprüngliche Verzeichnis erst dann zu löschen, wenn Sie geprüft haben, dass die gewünschten Dateien auch der Versionsverwaltung unterliegen.
Listing 3 zeigt das Vorgehen ausgehend vom Projektverzeichnis $HOME/project/. Das Erstellen des Bare-Repos erfolgt eine Ebene über dem Projektverzeichnis (Zeile 3). Das Klonen mit der Option bare erzeugt das Bare-Repo im Verzeichnis projekt.git (Zeile 4). Die Dateinamenserweiterung .git ist typisch für Bare-Repos. Wie das Listing zeigt, benötigen Kommandos, die sich auf ein Bare-Repo beziehen, keine explizite Angabe von .git.
Listing 3
### Bare Repo erstellen und auf den Server kopieren ### dazu eine Ebene nach oben wechseln $ cd .. $ git clone --bare projekt $ scp -r projekt.git git@raspberrypi:repos ### Verzeichnis umbenennen und vom Server klonen $ mv projekt projekt.org $ git clone git@raspberrypi:repos/projekt
Das Klonen erzeugt auf dem Arbeitsrechner das Verzeichnis projekt, überträgt die Dateien und setzt zudem einige Referenzen (Abbildung 2). Dazu gehören der Name des Remote-Repos und der beteiligten Zweige. Erfolgen keine weiteren Angaben, setzt Git den Namen des Remote-Repos auf origin und den der beiden Zweige auf master.
Abbildung 2: Mit git clone laden Sie Ihr Projekt auf den Git-Server.
Für Variante 2 erstellen Sie auf dem Server zunächst das Verzeichnis projekt.git und initialisieren dort ein Bare-Repo (Listing 4, Zeile 3 bis 6). Dann erstellen Sie im lokalen Repo die Verknüpfungen zu diesem Remote-Verzeichnis und schieben danach die Dateien auf den Server (Zeile 9 bis 12).
Listing 4
### Anmelden auf RasPi - Anwender git $ ssh git@raspberrypi git@raspberrypi:~ $ cd repos git@raspberrypi:~ $ mkdir project.git git@raspberrypi:~ $ cd project.git git@raspberrypi:~ $ git init --bare git@raspberrypi:~ $ exit ### Auf dem Arbeitsrechner $ cd $ cd projekt $ git remote add origin git@raspberrypi:repos/projekt $ git push -u origin master
Die Option -u in Zeile 12 bewirkt das Speichern der angegebenen Referenzen. Später nutzt Git diese beim Ausführen der Kommandos push und pull automatisch wieder (Abbildung 3). Im Gegensatz zu Variante 1 können Sie hier im Projektverzeichnis weiterarbeiten. Sind die Referenzen entsprechend gesetzt, kommen push und pull ohne weitere Angaben aus. Gesetzte Referenzen lassen sich bei Bedarf auch ändern.
Abbildung 3: Sind einmal die Referenzen gesetzt, kennt Git – wie hier bei git push – das Ziel.
Es empfiehlt sich, vorhandene Git-Projekte von Zeit zu Zeit in ein separates Verzeichnis zu klonen und zu prüfen, ob alle gewünschten Dateien auch unter Git-Kontrolle stehen. Die Kommandos git status und git ls-files, ausgeführt im jeweiligen Projektverzeichnis, leisten dabei wertvolle Dienste. Des Weiteren sollten Sie gleiche Zweige im Remote- und im lokalen Repo auch gleich benennen: Das erhöht die Übersichtlichkeit.
Das Remote-Repo ist nun erstellt und lässt sich mittels git clone git@raspberrypi:repos/projekt auschecken. Zugegeben, ein paar Nachteile gibt es da: So müssen Sie sich das Passwort merken und bei jeder Git-Aktion eingeben. Arbeiten mehrere Personen an dem Projekt, erfordert das Ändern des Passworts gar einen Rundbrief. Als Administrator haben Sie keine Möglichkeit zu kontrollieren, wer alles das Passwort kennt.
Darüber hinaus besitzt der Anwender git auf dem RasPi einen Shell-Zugriff. Das erlaubt ein versehentliches Löschen – beispielsweise das der Repos. Bei einer direkten Internet-Anbindung ist das noch problematischer.
Schlüsseldienst
Das bei der SSH-Authentifizierung weitverbreitete Public-Key-Verfahren löst das Passwortproblem. Das Verfahren basiert auf einem Schlüsselpaar aus privatem und öffentlichem Schlüssel. Beide liegen im Verzeichnis ~/.ssh/ im Home-Verzeichnis des jeweiligen Anwenders. Die Schlüsseldateien enthalten einzeilige ASCII-Zeichenketten (Abbildung 4).
Abbildung 4: Schlüsseldateien, wie hier der Public-Key, besitzen eine lesbare Kennung.
Der öffentliche Schlüssel wird in den SSH-Schlüsselbund des gewünschten Anwenders auf dem Host eingetragen, in diesem Fall in die Datei /home/git/.ssh/authorized_keys. Einmal bekannt gemacht, verwendet SSH die Public-Key-Authentifikation. SSH bietet eine Vielzahl an Konfigurationsmöglichkeiten [4]. Als Clients verwendeten wir im Test Systeme unter Debian 9, Fedora 29 und CentOS 7.5.
Windows und Git
Auch als Windows-Anwender erhalten Sie Zugriff auf die Inhalte des RasPi-Git-Servers. Dazu benötigen Sie eine für Windows taugliche Git-Bash [5], die auch gleich die SSH-Kommandos mitbringt. Unsere Tests mit zwei unterschiedlichen Windows-10-Systemen förderten keine Auffälligkeiten im Umgang mit den RasPi-Repos zutage. Das Einbinden des RasPi-Git-Servers in Eclipse funktionierte auch auf dem Microsoft-Betriebssystem problemlos (Abbildung 5). Da Windows die Dateien auf dem Git-Server nicht direkt zu sehen bekommt, sind diese gegen uneingeladene Gäste wie Trojaner mit Ransomware gut geschützt.
