Einer der bisher besten Vorträge wurde am heutigen Nachmittag von Scott Chacon zum Thema "Advanced Git Tricks" gehalten (Foliensatz, Cheat-Sheet). Bemerkenswert war insbesondere seine Lösung in Bezug auf Submodule, bei denen in Git normalerweise kein push auf den Remote-Host möglich ist. Tatsächlich verwendet Scott kein richtiges Submodul, sondern umgeht das Problem in der nachfolgend beschriebenen Vorgehensweise:

Ausgehend von einem Projekt mit Git-Repository soll ein weiteres Repository als Subprojekt eingebunden werden. Als Beispiel verwendet Scott einen Fork des Rack-Projektes, welches er dem eigentlichen Projekt als zusätzliche Quelle hinzufügt: $ git remote add rack_remote git@github.com:schacon/rack.git $ git fetch rack_remote Anschließend wird ein lokaler Branch erzeugt $ git checkout -b rack_branch rack_remote/master und dann wieder auf master zurück gewechselt: $ git checkout master Der Branch wird nun in die Arbeitskopie als Unterverzeichnis rack eingehängt: $ git read-tree --prefix=rack/ -u rack_branchAuf diese Art und Weise lässt sich Rack als Unterverzeichnis in das eigentliche Projekt einchecken:$ git add rack $ git commit -m 'added rack code' Angenommen, der lokale Benutzer führt nun Änderungen in Rack durch: $ vim rack/lib/rack.rb $ git commit -am 'added awesome to rack'Um diese Änderungen in das ursprüngliche Repository zu schieben, muss im Anschluss auf den Branch gewechselt werden: $ git checkout rack_branch $ git merge -s subtree --no-commit --squash masterDie Merge-Strategie subtree erlaubt es, den master von Rack in den Branch im Unterverzeichnis zu mergen. Außerdem werden durch die Option --squash mehrere Commits im Branch zu einem einzigem Commit zusammengefasst, so dass die lokale Historie keinen Übergang in das möglicherweise fremde Projekt findet.

Für weitere Tipps zu Git lohnt sich auf jeden Fall ein Blick in das Cheat-Sheet.

In einem neuen Repository verwendet Git für die E-Mail-Adresse des Autors den lokalen Benutzer- und Rechnernamen. Bei mir sieht das beispielsweise wie folgt aus:

$ git log commit c919d0966cb3dc0b1b6eaf8d585d48cb6baac7e6 Author: Thomas Dohmke <tom@mymac.local> Date: Wed Jan 21 23:48:54 2009 +0100

Initial revision.

Will man stattdessen die eigene E-Mail-Adresse verwenden, hilft folgender Befehl vor dem initialen Commit:

git config user.email 'E-MAIL'

E-MAIL ist durch die eigene E-Mail-Adresse zu ersetzen, in meinem Fall also:

git config user.email 'thomas@dohmke.de'

Man kann ebenfalls den angezeigten Namen ändern:

git config user.name 'NAME'

Letzteres ist u.A. dann sinnvoll, wenn mehrere Entwickler per Pair Programming gemeinsam an einem Stück Code gearbeitet haben. Ein passendes Ruby-Skript gibt es bei Bryan Helmkamp.

Um ein XCode-Projekt in Git anzulegen, habe ich ein kleines Shell-Skript geschrieben (Download), das folgende Schritte ausführt:

Ein leeres Git-Repository erzeugen. Die Datei .gitignore mit folgendem Inhalt erstellen:build .pbxuser *.mode1v3 .DS_StoreDamit werden das build-Verzeichnis, benutzerspezifische Dateien sowie die von Mac OS X angelegten .DS_Store-Müllhalden von der Versionierung ausgeschlossen. Die Datei .gitattributes mit folgendem Inhalt erstellen:.pbxproj -crlf -diff -mergeDer Parameter "-crlf" bewirkt, dass für Dateien mit der Endung .pbxproj keine Transformation der Zeilenumbrüche vorgenommen wird, "-diff" und "-merge" schließt den Vergleich (diff) und die Zusammenführung (merge) mit vorherigen Versionen aus. Den derzeitigen Stand in das Repository einchecken.

Der Aufruf im Terminal sieht dann wie folgt aus (nachfolgend als Beispiel für ein Cocoa-Projekt, das unter ~/Projects/PeachApp abgelegt wurde): $ cd ~/Projects/PeachApp $ xcode-git-init.sh Initialized empty Git repository in ~/Projects/PeachApp/.git/ Creating .gitignore. Creating .gitattributes. Commiting initial revision. add '.gitattributes' add '.gitignore' add 'English.lproj/InfoPlist.strings' add 'English.lproj/MainMenu.xib' add 'Info.plist' add 'PeachApp.xcodeproj/TemplateIcon.icns' add 'PeachApp.xcodeproj/project.pbxproj' add 'PeachApp_Prefix.pch' add 'main.m' Created initial commit 902b78f: Initial revision. 9 files changed, 3088 insertions(+), 0 deletions(-) create mode 100644 .gitattributes create mode 100644 .gitignore create mode 100644 English.lproj/InfoPlist.strings create mode 100644 English.lproj/MainMenu.xib create mode 100644 Info.plist create mode 100644 PeachApp.xcodeproj/TemplateIcon.icns create mode 100644 PeachApp.xcodeproj/project.pbxproj create mode 100644 PeachApp_Prefix.pch create mode 100644 main.m Finished. Have fun.

So bekommt man einfach und schnell ein Repository für ein XCode-Projekt, egal, ob es sich dabei um das nächste große Ding handelt oder nur um einen Prototypen. Denn wie schrieben Andy Hunt und Dave Thomas schon 1999:

Always Use Source Code Control. Always. Even if you are a single-person team on a one-week project. Even if it's a "throw-away" prototype. Even if the stuff you're working on isn't source code. Make sure that everything is under source code.

Aus The Pragmatic Programmer, Kapitel 17, Seite 86ff.

Nach den Anleitungen zu Git auf der iDisk und Git auf dem eigenen Server hier noch eine (dieses Mal) wirklich kurze Anleitung zur Benutzung von Git zusammen mit einer Dropbox:

Dropbox für den Mac runterladen, installieren und Konto einrichten. Vorteil gegenüber iDisk bzw. eigenem Server: Man bekommt 2GB Speicherplatz kostenlos. Ein neues Verzeichnis in der Dropbox erstellen, in welchem die Repositories aufbewahrt werden sollen:mkdir ~/Dropbox/Repositories In ein vorhandenes Git-Projekt wechseln, z.B.cd ~/Projects/PearApp Das Repository mit der Option "--bare" klonen. "--bare" bewirkt, dass nur das Repository an sich (das Verzeichnis .git), aber nicht die ausgecheckten Dateien des Projektes kopiert werden.git clone --bare . ~/Dropbox/Repositories/PearApp.git Den gerade angelegten Klone als weitere Quelle zum Projekt hinzufügen:git remote add dropbox ~/Dropbox/Repositories/PearApp.git Nun kann mit git pull dropbox und git push dropbox das lokale Repository mit der Version auf der Dropbox abgeglichen werden. Will man das Repository mit anderen teilen, so kann man entweder das Verzeichnis Repositories für andere Benutzer freigeben (Rechtsklick auf den Ordner im Finder, Menü Dropbox > Share) oder das Repository stattdessen im Verzeichnis Public abgelegen.

Verglichen mit der iDisk ist die Dropbox übrigens unglaublich schnell.

Schon wieder Git. Nach den Artikeln zu Git, iDisk und so und GitNub hat mich in den letzten Tagen beschäftigt, wie man Git-Repositories auf einem Server hosten kann, beispielsweise um diese der Allgemeinheit zur Verfügung zu stellen (man kann natürlich auch einfach github verwenden). Dabei stieß ich auf Gitosis und es entstand die nachfolgende kurze Anleitung.

Ausgangsbasis¶

Um beim Lesen nicht durcheinander zu kommen, sind Befehle, die auf dem Server einzugeben sind, mit dunklem Hintergrund und heller Schrift formatiert. Beispiel: uname

Befehle, die auf dem Client einzugeben sind, haben entsprechend einen hellen Hintergrund und dunkle Schrift. Beispiel:

uname

Für alle nachfolgenden Schritte wird davon ausgegangen, dass auf dem Server schon Git und Python (inkl. dem Paket Setuptools) installiert sind sowie ein Benutzer mit root- oder sudo-Rechten verfügbar ist. In meinem Fall lief auf dem Server Ubuntu Linux, die Anleitung sollte sich aber leicht auf andere Linux-Varianten anpassen lassen (sofern überhaupt Änderungen notwendig sind). Auf dem Client verwende ich Mac OS X 10.5, die Installation von Git kann man in einem älteren Beitrag nachlesen.

Installation & Konfiguration¶

Git-Repository von Gitosis klonen: cd ~ mkdir sources cd sources git clone git://eagain.net/gitosis.git Gitosis installieren: cd gitosis/ sudo python setup.py install Benutzer "git" anlegen: sudo adduser --system --shell /bin/sh --gecos 'git version control' --group --disabled-password --home /home/git git Mit den letzten beiden Parametern wird ein Login per Passwort deaktiviert und das Heimatverzeichnis des Benutzers auf /home/git gesetzt. Im nächsten Schritt muss der eigene öffentliche SSH-Schlüssel auf den Server kopiert werden. Zunächst ist zu prüfen, ob ein solcher schon existiert: ls ~/.ssh/id_rsa.pub Falls ja, direkt weiter mit dem nächsten Schritt. Falls nein, einen neuen Schlüssel erzeugen: ssh-keygen -t rsa Den Öffentlichen SSH-Schlüssel auf den Server kopieren: scp -P 10022 ~/.ssh/id_rsa.pub USER@SERVER:/tmp USER ist dabei durch den Benutzernamen auf dem Server, SERVER durch den Servernamen zu ersetzen. Zurück auf dem Server wird nun Gitosis initialisiert und dabei der eigene SSH-Schlüssel in die Liste der autorisierten Benutzer aufgenommen: sudo -H -u git gitosis-init < /tmp/id_rsa.pub Zum Schluss kann der gitdaemon gestartet werden, sofern ein öffentlicher Zugriff auf eines der Repositories gewünscht ist (Konfiguration der Rechte wird weiter unten beschrieben):sudo -u git git-daemon --base-path=/home/git/repositories/ Der Daemon läuft auf Port 9418, je nach Konfiguration des Servers müssen möglicherweise die Regeln einer vorhandenen Firewall angepasst werden.

Verwalten von Repositories¶

Die Verwaltung von Repositories und (wie wir später sehen werden) von Benutzern geschieht bei Gitosis über ein eigens dafür vorgesehenes Git-Repository, welches bei der Installation auf dem Server erzeugt wurde. Es lässt sich wie folgt auf dem Client klonen:

cd ~/Projects git clone git@SERVER:gitosis-admin.git

SERVER ist wiederum durch den Namen des Servers zu ersetzen. Da wir vorhin den eigenen öffentlichen SSH-Schlüssel auf den Server kopiert haben, ist kein Passwort notwendig.

Das Repository besteht grundsätzlich aus der Datei gitosis.conf zur Verwaltung der Repositories und Benutzer sowie dem Verzeichnis keydir, in dem die SSH-Schlüssel ablegt sind:

$ cd gitosis-admin/ $ ls -ln total 8 -rw-r--r-- 1 501 20 167 3 Jan 19:57 gitosis.conf drwxr-xr-x 4 501 20 136 3 Jan 19:57 keydir

Die Datei gitosis.conf enthält im initialen Zustand folgende Zeilen:

[gitosis]

[group gitosis-admin] writable = gitosis-admin members = tom@mymac

Der Abschnitt "group gitosis-admin" definiert eine neue Benutzergruppe mit dem Namen "gitosis-admin", die Schreibzugriff auf das Repository "gitosis-admin" hat und derzeit nur aus einem Mitglied "tom@mymac" besteht. "tom" ist hierbei mein lokaler Benutzername, "mymac" der Name meines Client-Rechners. Entsprechend enthält das Verzeichnis keydir eine Datei mit dem Namen tom@mymac.pub.

Ein neues Repository kann nun erzeugt werden, in dem folgende Zeilen der Datei gitosis.conf hinzufügt werden:

[group developers] writable = test members = tom@mymac

Das Repository hat hier den Namen "test", gehört zur Gruppe "developers" und nur mein eigener Benutzer "tom@mymac" hat darauf Schreibrechte. Im Prinzip hätte es auch ausgereicht, den Bezeichner "test" an die obige Zeile "writable = gitosis-admin" mit Leerzeichen getrennt anzuhängen. Es ist aber aus meiner Sicht sinnvoll, gleich von Anfang an die Repositories für Projekte vom Repository für die administrativen Aufgaben zu unterscheiden.

Nach Speichern der Datei gitosis.conf wird nun gitosis-admin eingecheckt und auf den Server geschoben ("push"):

git commit -a -m "Created repository test." git push

Damit hat "tom@mymac" Zugriff auf das Repository "git@SERVER:test.git", das Repository selbst existiert aber noch nicht und muss entsprechend angelegt werden:

cd ~/Projects mkdir test cd test git init git remote add origin git@SERVER:test.git

Hat man bereits ein Projektverzeichnis (egal ob mit oder ohne Dateien), kann der Aufruf von "mkdir test" entfallen. Anschließend können Dateien dem Projekt hinzugefügt und eingecheckt werden. Beispiel:

echo "This is a test file." > README git add README git commit -m "Initial revision."

Beim "push" auf den Server wird schlussendlich das Repository erzeugt:

git push origin master:refs/heads/master

Verwalten von Benutzern¶

Bisher hat auf das erzeugte Test-Repository lediglich der Benutzer "tom@mymac" Lese- und Schreibzugriff. Weitere Benutzer mit denselben Rechten können erstellt werden, indem diese dem Admin ihren öffentlichen SSL-Schlüssel zur Verfügung stellen. Angenommen, der Benutzer "joey@hismac" schickt seinen Schlüssel, dann sind folgende Schritte durchzuführen:

cd ~/Project/gitosis-admin cp ~/Download/joey@hismac keydir

In der Datei gitosis.conf ist der Benutzer der Gruppe "developers" hinzuzufügen:

[group developers] writable = test members = tom@mymac joey@hismac

Dann weiter im Terminal:

git add . git commit -m "Added joey to project test." git push

Will man das Repository hingegen für die Allgemeinheit mit Leserechten veröffentlichen (also ohne Abfrage von Benutzername und Passwort), muss auf dem Server die Datei git-daemon-export-ok innerhalb des Repositories erzeugt werden, sudo touch /home/git/repositories/test.git/git-daemon-export-ok

und ist dann wie folgt klonbar:

git clone git://SERVER/test.git

Damit endet dieser Artikel über Gitosis. Für weitere Dokumentation sei auf die README-Datei von gitosis verwiesen.

Kommentare, Fragen und Kritik sind wie immer herzlich willkommen.