git als Dateimanagement Lösung
Geschrieben von: Markus Junginger in Tools, tags: Dateimanagement, Dokumentenmanagement, Dropbox, git, Homecloud, SVN, Versionierunggit ist eine verteilte Versionsverwaltung für Dateien. Seinen Ursprung hat git in der Linux Welt: es wurde Linus Torvalds 2005 begonnen um das proprietäres System BitKeeper bei der Verwaltung des Linux Kernel Sourcecodes abzulösen. Viele Entwickler ziehen git Subversion inzwischen vor, vor allem weil ein verteiltes System einige Vorteile gegenüber einem zentralisiertem hat.
git hat einige Eigenschaften, die es auch für andere Zwecke jenseits der Entwicklung interessant machen. Ein Einsatz für “ganz normale” Dateien wie Office Dokumente oder andere Datendateien (vielleicht mit der Ausnahme von Mediendaten) hat einige Vorteile:
- Backup: Neben dem lokalen Repository kann man auch ganz leicht auf zweites anlegen, zu dem man die Veränderungen einfach pushen kann. Das zweite Repository liegt typischerweise im LAN, aber kann z.B. auch auf einer externen Festplatte eingerichtet werden. Im Prinzip können beliebig viele Repositories eingerichtet werden.
- Veränderungshistorie: Sämtliche Dateiversionen bleiben erhalten, auch wenn man mal eine Datei überschrieben hat.
- Verteiltes Arbeiten: Wenn man mehrere Rechner nutzt wird die Datei-Synchronisation schnell zur Herausforderung. Mit git kann man jeweils lokal (auch offline) arbeiten und dann einen Abgleich der Repositories triggern.
Insbesondere das verteilte Arbeiten ist eine Stärke von git und für mich ausschlaggebend einen Selbstversuch mit git für alle meine Datendatei zu machen. Bevor ich im nächsten Artikel zur Vorgehensweise etwas schreiben werden hier noch ein Vergleich von git zu Alternativen:
- Cloud-Storage: System wie z.B. Dropbox sind sehr einfach zu bedienen und verschmelzen mit dem Dateisystem des Betriebssystems. Bestimmte Ordner werden einfach in die Could repliziert und können von dort zu beliebigen anderen Rechnern synchronisiert werden. Zwar werden die Daten (Nutzer-spezifisch) verschlüsselt abgelegt, aber dennoch liegen die Daten damit nicht mehr im eigenen Einflussbereich. Zudem sind insbesondere die kostenlosen Angebote oft stark beschränkt in der Kapazität.
- Subversion: SVN erfordert einen zentralen Server, gegen den man sich synchronisieren kann. Um Änderungen zu committen muss man online sein. Während git sehr auf die Verwaltung großer Datenmengen optimiert ist, kann ein Abgleich bei Subversion schon mal etwas länger dauern. Auch störend ist, dass das Verschieben von Dateien unkomfortabel ist und dass Subversion in jedem Verzeichnis ein .svn Ordner für Metadaten anlegt. Was Windows Clients und Eclipse Plugins angeht, gibt es für Subversion jedoch noch die bessere Software.
Im nächsten Artikel möchte ich dann die Vorgehensweise inklusive der benötigten git Kommandos vorstellen. Bis dahin würde ich mich sehr über einen Austausch von Meinung und Erfahrungen freuen!
Einträge (RSS)
Ich hatte schon vor einiger Zeit Überlegungen in Hinblick zur Nutzung von Subversion für diesen Zweck. Besonders das verteilte Arbeiten nicht nur an mehreren Rechnern sondern auch zwischen verschiedenen Personen innerhalb verschiedener Organisation erscheint mir deutlich sinnvoller als das heute großteils noch praktizierte hin- und herschicken von Dateien via Email.
Bisher bin ich immer an Vorbehalten gescheitert, dass die Arbeit für nicht Entwickler mit einem solchen Werkzeug (selbst mit einem Windows Aufsatz vi Tortoise) zu kompliziert ist bzw. der Einrichtungsaufwand schlichtweg zu hoch ist.
Potential liegt aber in dem Thema auf jeden Fall.
Ich benutze Dropbox zusammen mit encfs, um die Dateien verschlüsselt an Dropbox zu übergeben.
http://progground.blogspot.com/2010/02/dropbox-encfs-timevault-easy-backup.html
Hej,
ich hab gerad deinen Beitrag gelesen und wollte das auch selbst einrichten. Bin beim Schauen, wie ich das wohl am Besten machen kann, auf deinen Artikel gestoßen… Noch sind keine Erfahrungen da, aber vielleicht in 2-3 tagen ;D.
Grüße,
Lena
Okay, ich hatte ja gesagt ich berichte Erfahrungen:
Ich hatte bisher schon ein paar git-Repositories rein lokal verwendet, um bei sowas wie meiner Bachelorarbeit eine Versionshistorie zu haben und notfalls mal ein paar Schritte zurück zu gehen. Das hat sich bewährt, steht jetzt aber der Verwendung von git als Backup-und-Synchronisationstool im Wege:
Git mag nämlich nicht wirklich verschachtelte Repositories. Es stört ihn, wenn in einem Repo ein anderes steckt, das mächte er dann als Submodule behandeln, was es aber eigentlich garnicht ist – ganz besonders dann, wenn man die Repos bis dato nur lokal verwendet hat, so wie ich.
Das führt letztendlich dazu, dass git entsprechende Verzeichnisse beim Synchronisieren auslässt – dabei sind das natürlich gerade die Verzeichnisse, an denen viel gearbeitet wird/wurde, und die ganz besonders dringend synchronisiert werden müssen. Gehen tut das natürlich, aber dann muss man die untergeordneten Repos wieder einzeln synchronisieren, und damit ist das ganze wieder etwas sinnfrei….
In kurz: Ich habe noch keine schöne Lösung für verschachtelte Repositories, die zwangsläufig entstehen wenn man einen “Dokumente”-Ordner hat wo alles drinsteckt – auch kleinere Programmierprojekte, die mit git verwaltet werden. Hat jemand eine?
Grüße,
Lena
Bei Subversion läßt sich die Verschachtelung über Eigenschaften von Ordnern lösen.
@Lena Schaue dir mal svn:external an. Damit läßt sich wunderbar verschachteln. Selbst relative Referenzcen auf andere Pfade im gleichen Repos gehen. Bin damit eigentlich ziemlich zufrieden.
@Lars:
Subversion tut aber in jeden Ordner einen .svn-Ordner. Das finde ich so unschön, dass ich lieber damit lebe, wie es jetzt ist…. ;D