Nachdem ich vor ein paar Tagen ein sehr interessantes Chaosradio Express über das Thema verteilte Versionskontrollsysteme gehört hatte, hab ich mir nun mal GIT angeschaut. Die Hauptvorteile gegenüber zentralisierten Systemen sind:

• man kann offline arbeiten und hat dabei trotzdem Zugriff auf alle Repository Ressourcen
• jeder Client das bekommt das komplette Repository
• sehr einfaches Branchen und Mergen – GIT kann sehr viel automatisch abfangen, es treten kaum Konflikte auf
• sehr geringer Speicherplatzverbrauch durch GIT – und keine .svn-Ordner in jedem Unterverzeichnis
• Performance!

Kurz gesagt: GIT macht fast alles besser als SVN.

Seinen Ursprung hatte das System in der Linux Welt. Linus Torvalds, der Erfinder von Linux, war mit den vorhandenen Versionskontrollsystemen nicht mehr zufrieden und entwickelte kurzerhand sein eigenes, welches die Vorteile aller Systeme zusammenführen sollte. Und es scheint ihm gelungen zu sein – GIT war geboren.

So, das erstmal als Vorgeplänkel. Wie ihr im Titel sehen könnt, geht es ja hier mehr um GIT in Verbindung mit SVN. Die Problematik ist nämlich, dass man bei sehr vielen Projekten auf Subversion gesetzt hat. Nun kann es zum einen sein, dass die Admins oder die Teammitglieder kein Interesse an GIT haben, die Zeit für eine Umstellung nicht vorhanden ist, oder der Chef einfach keine Lust auf Experimente hat. Genau für diese Fälle bringt GIT eine Sammlung von Tools mit, die z.B. als Brücke zwischen dem lokalen GIT Repository und einem entfernten SVN kommunizieren.

Tja, bei mir ist der Weggang von SVN vorerst auch keine Option, sodass ich mich genau mit diesen Tools beschäftigt habe. Ich möchte euch hier nun kurz zeigen, wie ihr euer Repository einrichtet, einen Checkout von SVN macht, etwas mit Eclipse ändert und das Ganze dann wieder ins SVN commited. Im speziellen befasse ich mich hiermit PHP Projekten, jedoch ist das GIT-Plugin für Eclipse universell einsetzbar – es ist also egal, welche Projektart ihr verwendet.

Zuallererst solltet ihr natürlich GIT installieren. Unter git-scm.com findet ihr die nötigen Installationsdateien. Für Mac gibt’s das obligatorische DMG Image, welches den Installer enthält. Nach erfolgreicher Installation seht ihr – nichts. GIT ist nämlich ein reines Kommandozeilentool. Also öffnet ihr zuerst das Terminalfenster.

Anschließend bewegt ihr euch in den Ordner, in dem ihr das Repository ablegen wollt bzw. den Checkout machen wollt. In meinem Fall ist es der “Sites” Ordner in meinem User-Verzeichnis – schließlich will ich mit versionierten PHP Projekten arbeiten. In SVN sind die Projekte ja meißtens in Unterordnern abgelegt, sodass der SVN-Pfad so aussieht:

svn://server/projektname

Ist dies der Fall, bewege ich mich also direkt in den “Sites” Ordner meines User-Verzeichnisses und erstelle keinen Projektordner. Durch den Checkout eines Projektes wird automatisch die Ordnerstruktur übernommen, sodass ich keinen Ordner für das Projekt anlegen muss. Wichtig: GIT arbeitet immer im aktullen Verzeichnis – achtet also darauf, dass ihr im richtigen Ordner seid.

Ok, also machen wir uns mal an den Checkout von SVN:

git svn clone svn://[server]/testprojekt

GIT legt nun automatisch den Ordner “testprojekt” an, erstellt darin das GIT Repository mit der kompletten SVN-History und kopiert sich anschließend die Base-Revision, also die aktuellste Version des Projekts, in diesen Ordner. Das GIT Repostitory liegt im Unterordner “.git”, welchen es, anders als bei SVN, nur einmal im Hauptordner gibt.

Das Repository steht, nur wird es ja sicherlich trotzdem im SVN hin und wieder neue Versionen von Dateien geben. Wir sollten also ab und zu an ein Update unserer Dateien denken. Das Update führt man einfach direkt im Projektordner, in unserem Fall “/Users/[Benutzername]/Sites/testprojekt”, durch:

git svn rebase

GIT findet nun alle nötigen Daten in seinen Einstellungen, die sich unter “testprojekt/.git” befinden – also auch, wo der SVN Server zu finden ist – und führt ein Update der geänderten Daten durch. GIT verhält sich an dieser Stelle wie ein normaler SVN Client.

So, damit haben wir schonmal den Hauptteil erledigt. Nun kümmern wir uns erstmal um Eclipse, bevor wir dann mal einen Commit ins SVN wagen.

Ich habe mich für das Plugin “eGit” entschieden. Ihr findet es unter eclipse.org als Eclipse Plugin. Nun wird es etwas schmutzig, da ich ehrlich gesagt nicht genau weiß, wie der Checkout von GIT mit dem Plugin funktioniert. Ich habe da echt ne Weile rumprobiert, bin aber nicht zum gewünschten Ergebnis gekommen – auch nicht über direkte Pfadangaben. Vielleicht kann mir ja hier jemand auf die Sprünge helfen.

Durch Zufall hab ich dann aber einen Trick gefunden, das Repo doch ganz leicht zu laden. Im Eclipse importiere ich erstmal “testprojekt” als bestehendes Projekt (geht natürlich nur, wenn das Projekt ein Eclipse Projekt ist – sonst müsst ihr erst eins anlegen!). Anschließend geht ihr auf “Team” –> “Share this projekt” und wählt da GIT aus. Anschließend wird euch direkt präsentiert, dass das Plugin an dieser Stelle bereits ein GIT-Repository gefunden hat, was man mit Finish bestätigt. Anschließend hat man das Projekt inklusive GIT Funktionen im Eclipse.

Ab dieser Stelle könnt ihr nun wie gewohnt commiten, nur das Updaten fällt weg, da GIT ja komplett auf eurer Platte liegt. Falls es in eurem Repository eine neuere Dateiversion geben sollte, klickt einfach mal auf Refresh und sie ist drin.

Nun führt ein paar Änderungen an den Dateien durch und speichert. Ihr seht, dass diese Dateien im Projektbaum mit einem vorgestellten “>” markiert werden. So seht ihr gleich, welche Dateien noch nicht commited sind. Führt nun einen Commit durch, anschließend geht es wieder in die Console.

Mit

git svn dcommit

führt ihr nun einen commit in euer SVN Repository durch. Das Tolle dabei ist, dass alle einzelnen Commits, die ihr in GIT getätigt habt, auch als einzelne Commits ins SVN wandern. Wenn ihr also eine Datei 3x bearbeitet und im Anschluss immer commited, dann werden diese 3 Änderungen auch 3x einzeln ins SVN gepostet. Ihr verliert also keinerlei History-Funktionen.

Bei mir kam es immer wieder vor, das GIT sich beschwerte, dass irgendwas mit dem Repository nicht stimmt bzw. nicht korrekt commited wurde und ich so das dcommit nicht ausführen konnte. In diesem Fall führt

git stash

aus. Damit reinigt ihr das Repository. Wichtig: vorher commiten, sonst sind eure Änderungen weg. “stash” bringt euer Working Directory wieder in Einklang mit der Head-Revision, also dem aktuellen Stand eures Repositorys.

Unter Windows wird der Vorgang wahrscheinlich sehr ähnlich sein, ich hab es mir aber noch nicht angesehen. Die GIT-Kommandos sind auf jeden Fall die gleichen.

Links:
Chaosradio Express 130 – verteilte Versionskontrollsysteme
GIT
SVN
eGit