geschrieben am Samstag, 5. März, 2011

Nachdem Ich ein bisschen Zeit mit verschiedenen Version Control Systems verbracht habe (z.B. SVN, CVS und Mercurial), entschied Ich mich mit Git zu arbeiten. Git ist klasse. Git ist schnell. Git ist einfach DAS Version Control System.

Git is awesome

Es gibt da draußen genügend Tutorials, in denen beschrieben wird, wie man mit Git arbeitet. Dateien aus dem Workspace in den Index adden, von dort aus ins lokale Repository committen, mergen, removen…. Ich könnte ewig so weiter machen. Was allerdings besonders cool an Git ist, sind sogenannte Bare-Repositories. Viele wissen es vielleicht schon – Ich sag’s trotzdem nochmal – Wenn man mit Git arbeitet hat man zunächst ein eigenes lokales Repository.

Man kann hier rumrocken wie man lustig ist. Das ist aber nicht alles. Neben dem normalen lokalen Repository ist es selbstverständlich möglich “verteilt” zu arbeiten. Verteilte Versionierung bedeutet eigentlich nichts weiter, als dass man beispielsweise ein zentrales Repository hat, in dem sämtliche Changes von außen zusammen geführt werden. Genau – quasi Github.

Dropbox ist unser Freund

Wer Dropbox benutzt, ist klar im Vorteil. Für die, die es nicht wissen, Dropbox ist ein Cloud-Dienst der euch die Möglichkeit gibt, irgendwo da draußen im großen World-Wide-Web, eure Daten an einem zentralen Punkt verfügbar zu machen. “Laaaangweilig, kennt man doch schon…” – richtig.

Die wahre Stärke von Dropbox ist das Teilen von Ordnern. Und genau das können wir nutzen, um uns eine Art Git-Server aufzusetzen.

Butter bei die Fische!

Genug gequatscht. Jetzt geht’s ans Eingemachte. Ich setze einfach mal voraus, dass gewisse Grundkenntnisse bezüglich der Verwendung von Git vorhanden sind. Als erstes kläre Ich mal kurz, was ein Bare-Repository ist. Erzeugt euch doch einfach mal einen Ordner und navigiert mit der Konsole in den Selbigen.

$ mkdir my_folder    // erzeugt einen Order 'my_folder' im aktuellen Verzeichnis
$ cd my_folder
$ ls    // Nach der Eingabe diesen Befehls ist nichts zu sehen, weil der Ordner leer ist

Okay, nun haben wir einen leeren Ordner. Schauen wir uns kurz an, wie ein Non-Bare-Repository so aufgebaut ist. Nachdem wir in unseren grad erstellten Ordner navigiert sind, erzeugen wir uns ein Git-Repository. Für die, die es nicht wissen: sowas macht man mit git init. Nachdem wir das Non-Bare-Repository initialisiert haben, werfen wir einen blick in das .git-Verzeichnis.

$ git init    // Git-Repository initialisieren
$ ls .git

Wundert euch nicht, dass ihr auf UNIX-Systemen das .git-Verzeichnis nicht sehen könnt. Dateien und Verzeichnisse, die mit einem “.” beginnen gelten als versteckt. In der Konsole könnt ihr Dateien und Verzeichnisse dieser Art ohne Probleme auflisten.

Nachdem ihr den Letzten der obigen Befehle ausgeführt habt, solltet ihr ungefähr sowas sehen:

HEAD
config
description
hooks
info
objects
refs

Dieses Verzeichnis repräsentiert euer komplettes Repository. Sämtliche Änderungen werden innerhalb der Verzeichnisse objects und refs festgehalten. Aber was ist nun der Unterschied zwischen einem Non-Bare und Bare-Repository? Ganz einfach. Es wird NUR in einem Non-Bare-Repository gearbeitet! Ihr könnt beispielsweise unterhalb von my_folder Dateien hinzufügen, verändern, löschen, verschieben usw. Das Bare-Repository dient lediglich als eine Art Proxy, um zwischen mehreren Entwicklern zu vermitteln. Genau genommen, vermittelt nicht das Bare-Repository, weil dies nicht weiß, dass es mehrere Non-Bare-Repositories gibt, welches mit diesem verknüpft sind.

Noch mehr Butter bei die Fische!

Schauen wir uns also an, wie ein Bare-Repository aufgebaut ist. Navigiert dazu einfach in eure Dropbox und erstellt ein entsprechendes Verzeichnis (in den letzten Jahren hat es sich so eingespielt, dass Bare-Repositories einen .git-Suffix im Namen haben). Nach der Erstellung des Verzeichnisses, begeben wir uns wieder in das Selbige und erzeugen wieder ein Git-Repository. Dieses mal allerdings ein Bare-Repository. Dafür muss man nichts weiter tun, als den Parameter –bare mitzugeben.

$ cd Dropbox/
$ mkdir my_folder.git
$ cd my_folder.git
$ git init --bare    // Bare-Repository erzeugen
$ ls

Das wars schon. Und nun kommen wir auf den Punkt zurück, den Ich vorhin erwähnte: Ein Bare-Repository hat kein Arbeitsverzeichnis. Wenn wir uns den Inhalt des Bare-Repositorys anzeigen lassen, stellen wir fest, das dies der Gleiche ist, wie der des .git-Verzeichnisses aus dem Non-Bare-Repository.

Und jetzt?

Der meiste Teil der Arbeit ist schon getan. Wir haben unser Bare-Repository in unserer Dropbox. Denkt daran, dass dieses Repository lediglich dazu dient, um Changes hinein zu pushen oder raus zu pullen, es wird nicht innerhalb dieses Repository gearbeitet. Und wie verknüpft man nun ein Non-Bare-Repository mit einem Bare-Repository?

Es gibt mehrere Wege dies zutun. Der wahrscheinlich einfachste Weg ist, einen sogenannten Klon des Bare-Repositorys zu erzeugen. Hier für gibt es den Befehl git clone und erwartet als Paramter den Pfad zum Bare-Repository und als zweiten Paramater den Namen des Verzeichnisses, in den der Klon erzeugt werden soll. Hier ein Beispiel:

$ git clone ~/Dropbox/my_folder.git my_folder    // Erzeugt den Ordner my_folder und klont das Repo

Führen wir den obigen Befehl aus, wir der aktuellste Stand des Master-Branch in my_folder geklont. Git erzeugt automatisch im Hintergrund die benötigten Remotes. Unser Non-Bare-Repository weiß also, dass es mit dem Bare-Repository in unserer Dropbox verknüpft ist. Was aber, wenn wir bereits ein Non-Bare-Repository haben und dies für andere verfügbar machen wollen? In diesem Fall können wir fast das Gleiche machen. Nur anders rum.

Wir klonen also von unserem Non-Bare-Repository und erzeugen ein Bare-Repository. Anschließend müssen wir dem Non-Bare-Repository nur noch sagen, dass es mit dem neuerzeugten Bare-Repository verknüpft ist (so das wir Changes in dieses pushen können). Dafür müssen wir dem Non-Bare-Repository nur den entsprechenden Remote hinzufügen. git remote add ist unser Freund.

$ git clone --bare ~/my_folder ~/Dropbox/my_folder.git
$ cd ~/my_folder
$ git remote add origin ~/Dropbox/my_folder.git
$ git remote update

Nun weiß unser Non-Bare-Repository, dass es ein Bare-Repository gibt. Pushen wir nun auf den Remote origin, landen alle unsere Changes im Bare-Repository. Den Dropbox-Ordner können wir nun mit Jemanden teilen, so dass auch andere in dieses Repository pushen und pullen können! Für die, die Github nutzen: Dort macht ihr nichts anderes.