git logoGit ist ein äußerst leistungsfähiges Versionierungssystem. Die Kernidee hinter Git liegt darin, dass es kein zentrales Repository im herkömmlichen Sinne mehr gibt. Repositories können beliebig geklont und wieder untereinander gemerget werden. Dabei wird jedoch oft ein Repository als Master angesehen. Dies entspricht in der Subversion-Welt dem zentralen Remote Repository. Ein weiterer Kernpunkt ist das einfache Erstellen von Branches sowie deren Merge in den Trunk. Mit diesen Eigenschaften ausgestattet, ist Git das ideale Versionierungssystem für verteiltes Arbeiten sowie die einfache Nutzung von Feature-Branchs.

Dienste wie github ermöglichen das Verwalten von Master Repositories und deren Zugriff über das Internet. Die Verwendung solcher Dienste ist für OpenSource-Projekte meist kostenlos, eine geschlossene Nutzung ist jedoch mit Kosten verbunden. Ein Ausweg liegt in der Nutzung des File-Cloud-Services Dropbox. Dropbox bietet einen kostenlosen Account an, der über eine Speicherkapazität von 2 GB verfügt. Der Account ist bei Dropbox schnell erstellt, womit es sich anbietet, ein Master-Repository auf eine solchen Account zu verwalten.

Erstellen des lokalen Repositories

Ausgangsszenario: Der erste Entwickler hat auf seinem System ein Maven-Projekt “ExampleTool” angelegt. Dieses soll nun mit Git versioniert werden. Zunächst wird dazu das Projektverzeichnis für Git vorbereitet, also ein lokales Repository angelegt:

$ git init

Im Projektverzeichnis befindet sich nun als Repository das Verzeichnis “.git”.

Bevor nun die Dateien des Projekts hinzugefügt werden, empfiehlt es sich, die Dateien und Verzeichnisse einzutragen, die Git  für die Versionierung ignorieren soll. Dazu wird im Projektverzeichnis eine Datei namens .gitignore angelegt, welche zum Beispiel folgenden Inhalt hat (Mac-tauglich, Maven-Projekt in Eclipse):

.DS_Store*
Thumbs.db
.project
.classpath
.settings
*.swp
target/**/*
target/*

Nun werden die zu versionierenden Dateien zum Git-Projekt hinzugefügt:

$ git add .

Nun sind die Dateien im Index des Git-Projekts registriert, jedoch nicht im Repository gespeichert. Dies erfolgt mit dem Befehl commit.

$ git commit

In diesem Schritt wird eine Liste aller zu sichernden Dateien angezeigt. Zudem muss noch ein Kommentar angegeben werden.

Wenn Sourcen mit dem Git-Befehl commit eingecheckt werden soll, erwartet Git die Eingabe eines Kommentars. Dazu öffnet beim Ausführen von commit den System-Editor. In unserem Beispiel wird der Text-Editor VI gestartet:

"i" oder "a"
...Kommentar tippen...
<ESC>
":wq"

Der letzte Befehl “speichert” den Kommentar und der commit-Vorgang wird ausgeführt.
Alternativ zum Abbrechen des commit-Vorgangs ist “:quit” oder “:q!” einzugeben.

Nun sind die Dateien also im lokalen Projekt-Repository gespeichert. Es kann nun beliebig mit den üblichen Git-Befehlen eine (lokale!) Versionierung der Änderungen erfolgen.

Ein zentrales Repository

Sollen mehrere Teilnehmer an dem Projekt arbeiten können, ohne das gleiche System zu verwenden (wie in vielen Git-Tutorials angenommen), muss ein Repository zentral als Master abgelegt werden, in das die einzelnen Änderungen der lokalen Entwickler-Repositories gemerget werden.

Für das Speichern eines Master Repositories gibt es verschiedene Alternativen:

  • eigener Git-Server
  • nutzen eines Git-Hosters wie z. B. github
  • oder als ganz einfache Alternative ein git-Repository in einem verteilten Dateisystem, so z. B. auf “alte” Weise NFS, Samba oder auf “modern” Dropbox und Co.

Ein Dropbox-Netzwerkverzeichnis wird mithilfe des Dropbox Clients als ein ganz normales Verzeichnis im Dateisystem repräsentiert, die Dateien liegen lokal vor und werden mit einem zentralen Server synchronisiert.

Da Dropbox-Verzeichnisse auch für andere Benutzer freigegeben werden können, wodurch die darin enthaltenen Dateien mit allen entsprechenden Benutzern synchronisiert werden können, eignet sich auch die Dropbox als Ablageort für ein zentrales Git-Repository.

Ausgehend davon, dass ein (für mehrere Benutzer) freigegebenes Verzeichnis existiert, können nun folgende Schritte durchgeführt werden:

Anlegen eines Repository-Verzeichnis in diesem freigegebenen Verzeichnis (optional)

$ mkdir /pfad/zur/Dropbox/shared-folder/gitrepositories

Nun wird ein Bare-Repository, also ein reines Git-Repository ohne ausgecheckte Projektdateien, in die Dropbox geklont:

$ git clone --bare . /pfad/zur/Dropbox/shared-folder/gitrepositories/ExampleTool.git

Zudem ist dem lokalen Git-Projekt noch dieses neue Remote-Repository bekannt zu machen, z. B. unter dem Kurznamen “dropbox”

$ git remote add dropbox /pfad/zur/Dropbox/shared-folder/gitrepositories/ExampleTool.git

Ein Abgleich mit diesem Repository ist nun mit git pull und git push einfach möglich:

$ git pull master
$ git push master

Verteiltes Arbeiten

Ein weiterer Entwickler, welcher ebenfalls Zugriff auf das Dropbox-Verzeichnis hat, kann das Projekt nun lokal klonen.

Dies geht auf zwei Arten:

Alternativ a) – ausführlich

Initialisierung eines Git-Projekts in einem leeren Verzeichnis

$ git init

Hinzufügen des remote-Repositories (wobei der Name und Pfad auch anders sein darf als beim ersten Entwickler)

$ git remote add dropbox /pfad/zur/Dropbox/shared-folder/gitrepositories/ExampleTool.git

Und holen aller Dateien

$ git pull dropbox master

Alternative b) – kurz

Diese Alternative vereinigt alle o.g. Schritte:

$ git clone /pfad/zur/Dropbox/shared-folder/gitrepositories/ExampleTool.git .

Nun kann auch Entwickler 2 lokal versioniert arbeiten. Beide Entwickler können nun unabhängig voneinander Änderungen vornehmen.

Code, welcher die notwendige Reife zum Teilen mit den anderen Entwicklern gefunden hat, wird einfach mit git pull über das Dropbox-Verzeichnis synchronisiert.

Mögliches Risiko

Ob nun Dropbox gegenüber einem Server oder Hosting-Dienst vorzuziehen ist, ist diskussionswürdig.

Interessant sind sicherlich mögliche Konflikte, wenn mehrere Entwickler ein “pull” in das Dropbox-Repository ausführen, während sie (oder mindestens einer) offline sind.

Hier könnte durchaus ein Synchronisierungsproblem seitens Dropbox entstehen, sodass ein korruptes Git-Repository entstehen kann.

Daher eine Frage an unsere Leser: Gibt es hierzu bereits Erfahrungen? Scheibt gerne einen Kommentar dazu unter diesem Artikel.

Quellen

Einleitung in Git: http://www.debianroot.de/server/einleitung-die-benutzung-von-git-1144.html
Git & Dropbox: http://www.komprovisation.de/blog/git_auf_der_dropbox
Remote Repositories: https://github.com/casparjones/Git-Tutorial/wiki/3.-Tutorial:-Remote-Repos

Autoren: Andreas Hohendorf, Stephan Scharff-Rahn

3 Kommentare für “Git-Repos in der Dropbox

  1. Also ich mag schon mal die Idee..
    Als spielwise geht es auf jeden Fall denke ich. Und wenn man dann mit der Dropbox an die Grenzen stößt, kann man ja mit git jederzeitl relativ problemlos umziehen. ;)

  2. Ich find die Idee nett, auch wenn, wie schon bemerkt, damit die Integrität des Repos at Risk is. Dies aber auch nur wenn wirklich gleichzeitig gearbeitet wird. Ich bin immer nur an anderen Stellen. Die Offline-Thematik liesse sich ggf. dadurch lösen, dass man das zentrale Repo in einer TrueCrypt Datei versenkt. Diese läßt sich nur als Ganzes syncen. Dropbox erkennt ggfls. einige Fehlersituationen und markiert “splits”. (Funktioniert mit meiner Faktur, warum nicht mit GIT). In keinem Fall geht ein push/pull. verloren und sollte man doch mal ein Offline-Update überholen, wird es beim nächsten Push garantiert hochgeschoben. Nur beim Löschen eines lokalen Repos, muss man sicherstellen dass wirklich alles online im sync ist. Und da bietet sich ein gezipptes Backup auf Dropbox an.

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


1 × = neun

Sie können folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>