Komprovisation

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

1. Ein leeres Git-Repository erzeugen.
   
   
2. Die Datei .gitignore mit folgendem Inhalt erstellen:

   build
   *.pbxuser
   *.mode1v3
   .DS_Store

   Damit werden das build-Verzeichnis, benutzerspezifische Dateien sowie die von Mac OS X angelegten .DS_Store-Müllhalden von der Versionierung ausgeschlossen.
   
   
3. Die Datei .gitattributes mit folgendem Inhalt erstellen:

   *.pbxproj -crlf -diff -merge

   Der 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.
   
   
4. 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:

1. Dropbox für den Mac runterladen, installieren und Konto einrichten. Vorteil gegenüber iDisk bzw. eigenem Server: Man bekommt 2GB Speicherplatz kostenlos.
   
   
2. Ein neues Verzeichnis in der Dropbox erstellen, in welchem die Repositories aufbewahrt werden sollen:

   mkdir ~/Dropbox/Repositories

3. In ein vorhandenes Git-Projekt wechseln, z.B.

   cd ~/Projects/PearApp

4. 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

5. Den gerade angelegten Klone als weitere Quelle zum Projekt hinzufügen:

   git remote add dropbox ~/Dropbox/Repositories/PearApp.git

6. 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

1. Git-Repository von Gitosis klonen:

   cd ~
   mkdir sources
   cd sources
   git clone git://eagain.net/gitosis.git

2. Gitosis installieren:

   cd gitosis/
   sudo python setup.py install

3. 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.
   
   
4. 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

5. 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.
   
   
6. 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

7. Je nach Debian-Version kann es notwendig sein, noch folgende Rechte zu setzen (siehe Kommentare von Wir und MacLovin):

   chmod 750 /home/git/repositories/gitosis-admin.git/hooks/post-update

8. 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.

Zufällig bin ich heute über ein kleine, aber feine Anwendung namens GitNub gestolpert, dessen Zweck auf der eigenen Homepage wie folgt beschrieben wird:

A Gitk-like application written in RubyCocoa that looks like it belongs on a Mac.

Gitk ist eine mit Git mitgelieferte Anwendung, um Änderungen in einem Git-Repository grafisch nachvollziehen zu können. Nachfolgend ein Screenshot.

Wie man sieht, fühlt sich Gitk nicht sehr mac-like an. Mal schauen, ob GitNub das besser kann.

Die Installation erfolgt unter Mac OS X 10.5 mit folgenden Schritten (unter der Voraussetzung, das bereits XCode und git installiert sind):

1. RubyCocoa runterladen und installieren
2. Folgende Gems installieren:

   sudo gem install open4 mime-types

3. Im Terminal in ein geeignetes Verzeichnis wechseln, z.B.

   cd ~/source

4. Git-Repository von GitNub samt Untermodulen klonen:

   git clone git://github.com/Caged/gitnub.git
   cd gitnub
   git submodule init
   git submodule update

5. GitNub kompilieren:

   rake build

6. GitNub.app nach /Applications und nub nach /usr/local/bin kopieren:

   rake install

7. Symbolischen Link in /usr/bin erstellen (sonst findet TextMate nub nicht):

   ln -s /usr/local/bin/nub /usr/bin/nub

Nun kann man aus jedem beliebigen Git-Repository einfach nub aufrufen, z.B. in dem Git-Repository, welches wir für GitNub in Schritt 4 geklont haben:

nub

Links neben dem Suchfeld stehen drei Ansichten zur Verfügung: In der ersten Ansicht (siehe oben) werden alle Änderungen dargestellt. In der zweiten Ansicht kann man sich das "Netzwerk" des Projektes auf GitHub (sofern es sich um ein solches Projekt handelt) anschauen. In der dritten Ansicht erscheint links das Projektverzeichnis. Wählt man dort eine Datei aus, wird diese rechts dargestellt und man kann erkunden, welche Zeile der Datei von welchem Autor zuletzt eingecheckt wurde (die Bilder der Autoren holt sich GitNub übrigens von Gravatar).

Einfach und schick, werde ich zukünftig sicher ausgiebig benutzen.

Am 03. Mai 2007 gab Linus Torvalds einen Google Tech Talk Linus Torvalds on git über das ursprünglich von ihm entwickelte Versionskontrollsystem Git. Der Vortrag ist stark geprägt von Linus' persönlichen Ansichten, dennoch war er der Anlass für mich, mal einen Blick auf Git unter Mac OS X zu werfen.

Installation

Für die Installation gibt es gleich mehrere Wege. Man kann den git-osx-installer runterladen, Git selber kompilieren wie im Artikel Installing Git 1.5.2.4 on Mac OS X Leopard beschrieben, oder einfach MacPorts verwenden, das ich eh schon installiert hatte. Mit letzterem genügt es, die Zeile

sudo port install git-core +svn

im Terminal einzugeben und ein paar Minuten zu warten. Nach Abschluss der Installation erzeugt der Befehl

which git

die folgende Ausgabe:

/opt/local/bin/git

Erstellung eines lokalen Repository

Ein lokales Repository lässt sich mit einem einzigen einfachen Befehl erzeugen, sofern man zuvor in das jeweilige Projektverzeichnis gewechselt hat (z.B. ~/Projects/PearApp):

cd ~/Projects/PearApp
git init

Dabei spielt es keine Rolle, ob sich in diesem Verzeichnis schon Dateien befinden. Der Befehl legt lediglich ein neues Verzeichnis .git an, welches sämtliche Dateien des noch leeren Repository enthält.

Hinzufügen von Dateien

Das Hinzufügen einer Datei oder eines Verzeichnisses zum Repository geschieht mit folgenden Befehl:

git add PearApp.xcodeproj

Git durchsucht dabei angegebene Unterverzeichnisse rekursiv und berücksichtigt die darin gefundenen Dateien. Ergo lassen sich alle Dateien eines Projektes mit folgendem Befehl hinzufügen:

git add *

Will man eine ausführlichere Ausgabe erhalten, fügt man vorher den Parameter -v hinzu,

git add -v *

oder lässt sich nachträglich den Status anzeigen:

git status

Schließlich beendet man den Vorgang mittels

git commit -m "Initial revision."

Die Zeichenkette hinter dem Parameter -m beschreibt die Änderungen als so genannte "Commit Message". Lässt man den Parameter weg, so öffnet sich automatisch der bevorzugte Editor, um dort entsprechenden Text einzugeben.

Schieben und Ziehen

Einer der wesentlichen Unterschiede zwischen Git und anderen Versionskontrollsystemen, wie z.B. CVS oder Subversion, ist der dezentrale Ansatz. Es existiert kein zentraler Server, auf dem das einzige Repository gespeichert ist. Stattdessen besitzt jeder Benutzer seine eigene lokale Kopie des Repository. Jede Kopie ist im gewissen Sinne gleichberechtigt, d.h. es existiert per Definition kein Hauptentwicklungszweig des Projektes.

Zurück zum Beispielprojekt. Bisher liegt das erstelle Repository lediglich lokal unterhalb des Projektverzeichnisses. Will man mit mehreren Entwicklern zusammen arbeiten oder einfach seine Daten vor einer kaputten Festplatte, Diebstahl oder dem versehentlichen Löschen des Verzeichnisses bewahren, ist es sinnvoll, eine Kopie auf einem räumlichen getrennten Speicherplatz zu sichern. Ich verwende dafür die iDisk meines MobileMe-Kontos. Diese lässt sich so einrichten, dass sie auch offline verwendet werden kann und bei einer Verbindung mit dem Internet automatisch synchronisiert wird. Dazu ist in den Einstellungen von .mac lediglich der Button "Start" im Bereich "Synchronisierung der iDisk" zu drücken.

Die iDisk ist fortan im Verzeichnis /Volumes/${USERNAME} ansprechbar, egal ob man online oder offline ist. Das lokale Repository wird über den folgenden Befehl in ein Unterverzeichnis der iDisk geklont,

mkdir /Volumens/${USERNAME}/Repository/
cd ~/Projects/PearApp
git clone --bare . /Volumes/${USERNAME}/Repository/PearApp.git

und anschließend als zusätzliches Repository dem Projekt hinzugefügt:

git remote add idisk /Volumes/${USERNAME}/Repository/PearApp.git

Der Bezeichner nach "add" kann beliebig gewählt werden, das initiale Repository heißt stets "master", für das Repository auf der iDisk fiel meine Wahl auf "idisk".

Zwischen beiden Kopien tauscht man Dateien mittels Ziehen ("pull") und Schieben ("push") aus. Habe ich die Arbeit an einer Datei beendet, übergebe ich die Datei dem lokalen Repository ("commit") und schiebe dieses in das Repository auf der iDisk:

git commit -m "Did some changes." 
git push idisk

Umgekehrt ziehe ich Dateien von der iDisk, wenn ich diese beispielsweise im Büro bearbeitet und von dort aus eingecheckt habe:

git pull idisk

Stellt sich noch die Frage, wie bekomme ich überhaupt eine Kopie des Repository im Büro? Nichts einfacher als das:

git clone /Volumes/${USERNAME}/Repository/PearApp.git

Mehr Informationen

Zum Schluss noch ein paar Links zu Git, wovon besonders der letzte für Benutzer von Subversion interessant sein dürfte, beschreibt er doch die Benutzung von Git im Vergleich zu Subversion.

• Git Homepage
• Git Wiki
• Git User's Manual
• Everyday GIT With 20 Commands Or So
• Git SVN Crash Course