Git - ein wahrer Teamplayer

Git in Kombination mit anderen Systemen
Kommentare

Softwareanwendungen können heutzutage nicht ohne Versionsverwaltung leben. Beim Großteil der Anwendungen werden dafür Systeme wie SVN oder CVS verwendet. Aber auch Git ist wegen seiner Flexibilität

Softwareanwendungen können heutzutage nicht ohne Versionsverwaltung leben. Beim Großteil der Anwendungen werden dafür Systeme wie SVN oder CVS verwendet. Aber auch Git ist wegen seiner Flexibilität und vieler anderer Vorteile inzwischen sehr populär geworden. Besonders interessant wird der Einsatz von Git in der Verknüpfung mit den Features von SVN oder CVS in einem Projekt. Der folgende Beitrag veranschaulicht, wie bestehende Applikationen, die bereits ein Versionskontrollsystem nutzen, gleichzeitig mit Git verbunden werden können und welche Vorteile sich daraus ergeben.

Git hat sich mittlerweile zum starken Konkurrenten sowohl aller zentralen (SVN, CVS und RCS) als auch lokaler Versionsverwaltungssysteme wie Mercurial und Bazaar entwickelt. Im Februar 2010 wurden im Rahmen einer Umfrage [1] die wichtigsten Versionierungssysteme miteinander verglichen. Dabei stellte sich heraus, dass Git eine beachtliche Bedeutung in diesem Umfeld innehat: Es erhielt die höchste Punktzahl in der Bewertung. Es gibt zahlreiche Einführungen in die Arbeit mit Git. Auch wurde bereits ausgiebig darüber referiert, welche Vorteile User genießen, die statt SVN oder CVS Git verwenden. Doch bisher ist noch niemand auf die Idee gekommen, ein zentrales oder lokales Versionsverwaltungssystem wie SVN „ohne git-svn“ oder CVS „ohne git-cvsimport“ mit Git in ein und demselben Projekt zu kombinieren, um die Vorteile aller Features zu bündeln und den größtmöglichen Nutzen daraus zu ziehen. Diese innovative Methode soll hier näher vorgestellt werden. Darüber hinaus wird gezeigt, wie man Git als Cloud-Lösung verwenden kann.

Git versus zentrale Versionsverwaltung

Im Gegensatz zu zentralen Versionsverwaltungssystemen verwendet ein verteiltes Versionsverwaltungssystem kein zentrales Repository. Jedoch verleiht gerade dieses Merkmal einem verteilten Versionsverwaltungssystem mehr Stärke, da das System vom Netzwerk unabhängig ist. Git zählt zu den verteilten Versionsverwaltungssystemen. Es greift ausschließlich beim Abgleich mit Branches auf anderen Repositories auf den Netzwerkbefehl zurück. Die lokalen Git-Daten sind immer ein vollwertiges Repository für das Projekt, in dem es angewendet wird. Bei Git besitzt jeder User ein eigenes Repository, in das er seine Änderungen einpflegen kann. Git ist zudem ein extrem schnelles System. Das Austauschen von Änderungen kann enorm vereinfacht werden, zum Beispiel bei der Erstellung vollwertiger Clones auf GitHub und Google Code, da Git unabhängig vom Netz ist.

Trotz seiner zahlreichen Vorzüge soll Git hier aber nicht in den Vordergrund gestellt werden. Vielmehr soll das Augenmerk auf der Kombination von Git mit einem Versionierungssystem liegen sowie auf den Vorteilen, die Git als Cloud-Lösung bietet.

Lifecycle-Status einer Datei mit Git

Abbildung 1 zeigt die einzelnen Status eines Git-Files. Es gibt im Grunde genommen vier Zustände [2]: Eine Datei kann „untracked“ sein (Zustand 1) bzw. nicht versioniert, „unmodified“ (Zustand 2) – was bedeutet, dass die Datei schon versioniert ist, aber noch nicht verändert. Der dritte Zustand ist „modified“. Die Datei ist also schon versioniert, aber noch nicht „staged“. Befindet sich die Datei schließlich im Stage, also im vierten Zustand, ist sie noch nicht „committet“.

Abb. 1: Lifecycle-Status eines Files mit Git

Git ist ein unkompliziertes, sehr effizientes System und als solches besonders geeignet für User, die es lieben, immer und überall zu programmieren. Sei es im Zug, beim Auslandsaufenthalt oder sogar am Strand – Git macht’s möglich, auch wenn das heimische Firmennetzwerk nicht verfügbar ist. Projekte können auf diese Art viel schneller und effektiver bearbeitet und abgeschlossen werden. Dies spart also nicht nur Zeit, sondern auch Geld.

Bei Git gibt es die Möglichkeit, die einzelnen Änderungen zu historisieren und diese dann gemeinsam und gleichzeitig zu SVN oder CVS hochzuladen. Aber was machen Softwareentwickler, wenn sie z. B. auf Reisen oder am Wochenende zu Hause mit einem SVN- oder CVS-Projekt beschäftigt sind? Sie möchten dann natürlich auch Änderungen, die sie fernab vom Schreibtisch gemacht haben, historisieren, damit sie nicht verloren gehen. Die Antwort liegt auf der Hand: Git verwenden! Allerdings – wie geht das mit SVN oder CVS?

Git und SVN

Zunächst stellt sich die Frage, wie sich die Historisierung der Daten steuern lässt. Programmierer, die beim Entwickeln eine IDE wie Eclipse, IntelliJ oder auch Visual Studio verwenden, wissen, dass all diese IDEs eine Funktion zur Historisierung von Dateiänderungen bieten. Diese birgt aber auch einige Nachteile. So ist die Historisierung in den IDEs nicht für einen längeren Zeitraum möglich. Auch kann man Änderungen nicht wie in einem System effektiv anschauen und darstellen. Ein weiteres Handicap ist, dass die IDEs keine lokalen Branches oder Tags erstellen können. Infolgedessen kann man die Historisierung mithilfe einer IDE nicht zweckmäßig abschließen.

Welche Möglichkeiten gibt es nun, Git mit einem SVN-Projekt zu kombinieren? Im Gegensatz zu den zentralen Versionsverwaltungssystemen werden bei den verteilten Versionsverwaltungssystemen alle Änderungen lokal committet. Danach kann man diese Änderungen in der Cloud bzw. im Netz committen. Die naheliegendste Methode, Git mit SVN nutzen zu können, ist die Verwendung des Prozesses Git-SVN. Diese Funktion bietet Git von Haus aus, denn sie ist eine Standardmethode, wenn Git als Konsolensystem für Linux bzw. Mac OS installiert wird. Aber leider fehlt dieser Prozess in vielen Git-GUI-Systemen – ebenso wie viele Git-Plug-ins für die IDEs. Um ein vorhandenes SVN-Projekt mit Git kombinieren zu können, muss zuerst dieses Projekt mit Git geklont werden. Git-SVN bietet dafür eine Möglichkeit:

git svn clone –stdlayout http://svnProjectPath

Die Option stdlayout beinhaltet, dass Git auch Dateien aus Branches und Tags mit herunterlädt. SVN kennt das Konzept Git/branch und Git/tags nicht. Ist dies geschehen, kann man mit Git normal weiterarbeiten. Die meisten Git-Funktionen wie add, commit, branch usw. können dabei verwendet werden. Möchte man dann die Änderungen auch in Git committen, verwendet man commit. Zum Beispiel:

$git commit -am 'Fixed some Issues in index.html'
[master 6e40d02] Fixed some Issues in index.html
 1 files changed, 1 insertion(+), 1 deletion(-)
 rewrite index.html (100%)

Wenn man danach die Änderung auch in SVN committen möchte:

$ git svn dcommit
Committing to http://svnProjectPath
  M index.html
Committed r79
  M index.html

Vor- und Nachteile der Git-SVN-Verwendung

Git-SVN ist das perfekte Werkzeug, um mit Git zu beginnen, ohne radikale Veränderungen an der Organisation durchführen zu müssen. Bedauerlicherweise bringt dieses Tool aber viele Nachteile mit sich. Das Committen und Auschecken von Projekten beansprucht sehr viel Zeit, was besonders bei umfangreichen Projekten, die lange in einem SVN-Repository existierten, nicht sehr hilfreich ist. Darüber hinaus können beim Mergen Konflikte entstehen. Nur um einen Eindruck davon zu vermitteln: Es gibt mehr als 11 000 Einträge bei stackoverflow.com zum Suchbegriff „git-svn Problem“. Außerdem funktioniert das Werkzeug ausschließlich in SVN-Projekten. Das bedeutet: Wenn man ein CVS-Projekt hat und dieses parallel mit Git verwenden möchte, ist das leider nicht mit dem Git-SVN-Tool möglich.

Es bedarf zudem eines gewissen Know-hows, um dieses Tool zu nutzen. Die meiste Arbeit wird auf der Konsole erledigt, da Git-SVN nicht von vielen GUI-Tools und Plug-ins angeboten wird. Unter [3] findet man eine Liste grafischer Frontends und Tools.

Einen der größten Nachteile hat Scott Chacon in seinem Buch „Pro Git“ [4] gezeigt, nämlich, dass bei den Git-SVN-Commits bzw. bei der Verwendung von „git svn dcommit“ für jedes Commit ein Subversion Commit gemacht und dann das lokale Git umgeschrieben wird, um einen spezifischen Identifier zu inkludieren. Das bedeutet, dass sich alle SHA-1 Checksums der Commits eines Programmierers ändern. Daran erkennt man, dass das gleichzeitige Arbeiten mit Git-basierten Remote-Versionen in den Projekten eines Entwicklers und einem Subversion-Server nicht sinnvoll ist. Schaut man sich das letzte Commit an, sieht man, dass die neue Git-SVN-ID hinzugekommen ist. Die SHA Checksum, die z. B. ursprünglich mit 97031e5 beim Committen begann, startet nun mit 938b1a5. Will man sowohl zu einem Git-Server als auch zu einem Subversion-Server pushen, muss man zuerst zum Subversion-Server pushen (dcommit), weil diese Aktion die Commit-Daten ändert.

Git und CVS

Für all die schönen Projekte, bei denen immer noch CVS verwendet wird, gibt es auch die Möglichkeit, mit Git zu arbeiten. Mithilfe des „git-cvsimport“ Tools kann man CVS-Projekte importieren, um sie mit Git zu klonen. Ein CVS-Projekt wird folgendermaßen mit Git initialisiert:

$git cvsimport -d $CVSROOT -C dir_to_create -r cvs –k -A /path/to/authors/file cvs_module_to_checkout

Das A aus dem cvsimport ist optional, aber es hilft dabei, die Historisierung mit Git harmonisieren zu können und mehr nach Git auszusehen.

Die erste Erstellung nimmt noch vergleichsweise viel Zeit in Anspruch. Nach der Initialisierung wird ein „master“ erstellt. Dabei gibt es bestimmte Konfigurationen, die hilfreich sind, wenn man mit Git und CVS arbeitet:

$ git config cvsimport.module cvs_module_to_checkout
$ git config cvsimport.r cvs
$ git config cvsimport.d $CVSROOT

Hierbei werden die Konfigurationen für die CVS-Module, den CVS-Import und den Root festgelegt, sodass man sie nicht jedes Mal neu eingeben muss. Um die Änderungen wieder in CVS spiegeln zu können, verwendet man das git cvsexportcommit.

Die Benutzung stellt den Programmierer jedoch vor einige Herausforderungen. Wie bei Git-SVN funktioniert dies nur in einem ausschließlich CVS-fähigen Projekt. GUI-Tools oder Plug-ins für Eclipse oder IntelliJ existieren leider nicht. Und zu guter Letzt kann es nach dem Klonen Probleme mit den Standard-Git-Funktionen geben.

Tipps zur Verwendung von Git mit anderen Systemen

Nachdem nun Für und Wider der Kombination eines SVN- oder CVS-Systems mit Git und die Verwendung von git-svn sowie svn-cvs-import erörtert worden sind, wollen wir uns meiner konkreten Alternativlösung zuwenden. Es handelt sich dabei um eine eigentlich simple Idee, die aber eine höchst effiziente Wirkung hat: die Git-Initialisierung jedes beliebigen SVN- oder auch CVS-Projekts ohne Verwendung zusätzlicher Tools.

Hierfür ist „Metadata“ das Schlüsselwort. Bei Git gibt es das Repository Metadata .git. Alle Projekte bzw. Dateien, die mit einem Versionsverwaltungssystem verbunden sind, sehen nur diese Metadaten. Ein Subversion-Projekt beispielweise speichert seine Historie und auch die gesamte Verwaltung in einem Verzeichnis namens .svn. Subversion kontrolliert den gesamten Tree anhand dieses Verzeichnisses. Was passiert, wenn man innerhalb eines Subversion Directory Git initialisiert?

$git init
Initialized empty Git repository in /user/walid/svnProject/.git/ 

Nun hat man plötzlich ein Git-Repository innerhalb eines SVN-Directory erstellt. Dabei kann man alle Git-Funktionalitäten und die damit verbundenen Vorteile verwenden. Man kann Branches und Tags erstellen, Dateiänderungen committen und auch diese Veränderungen nachvollziehen, ohne SVN in Betracht ziehen zu müssen.

Allerdings gibt es einen Trick, den es zuvor anzuwenden gilt: Man muss die SVN-Metadata in Git ignorieren. Das geht einfach, indem man eine Datei mit dem Namen .gitignore im Hauptverzeichnis des Projekts erstellt und die Metadata .svn eingibt. Daraufhin wird Git die gesamten Metadaten des SVNs ignorieren. Man kann auch diese Bemerkung in .git/info/exclude.git/info/exclude erstellen. Hat man Git bereits unter Linux bzw. Mac OS installiert, erstellt es automatisch im aktuellen Arbeitsverzeichnis eine Datei mit dem Titel .gitignore_global. Dort kann man auch alle denkbaren ignorierbaren Dateien hinterlegen. Abbildung 2 zeigt ein SVN-Projekt, das nachträglich mit Git initialisiert wurde.

Abb. 2: Strukturdarstellung eines GIT-SVN-Projekts

Nach diesem Prinzip kann man alle zentralen Verwaltungssystemprojekte zusammen mit Git steuern. Ein großer Vorteil liegt darin, dass Entwickler immer unabhängig vom Netz arbeiten können. Sie verwenden die Benefits von Git und sind somit frei von den Nachteilen von SVN-Git. Ob am Strand, im Zug oder im Central Park am Ententeich – man hat stets sein eigenes Repository dabei. Ein kleiner Nachteil ist, dass SVN diese Änderungen nicht mitbekommt und sie nicht zentral gespeichert werden. Aber sie gehen selbstverständlich nicht direkt verloren, denn man kann sie nachträglich zur SVN committen und zentral speichern.

Wir haben bis jetzt über Sourcecode, SVN, CVS und Git gesprochen – aber was ist mit Doc? Man kann Git auch als Cloud-Lösung verwenden, um Dateien wie Doc und Excel speichern und zentral verwalten zu können. Auf Google-Doc oder Dropbox kann verzichtet werden, wenn man einen virtuellen Server schafft, um Git für die Verwaltung der einzelnen Dokumente benutzen zu können. Zum Beispiel so: Im Remote-Server muss ein leeres Repository erstellt werden mit

$git init –bare

Danach klont man dieses Repository:

$git clone me@vserver.com:/docs

So kann man letztendlich seine Dateien immer nachvollziehen und stets zentral und sicher von jedem System aus verwalten. Ein kleiner Nachteil, wenn man ihn überhaupt als solchen bezeichnen will, ist, dass man die Änderungen selbst committen und verwalten muss, weil es kein Tool dafür gibt, das sie im Hintergrund batcht. Es gibt aber auch dafür einen Trick: Anstatt immer mit git add und dann mit git commit zu arbeiten, gibt es die Möglichkeit, diese in einem Schritt ausführen zu können. Dafür muss man nur ein Alias erstellen:

git config –global alias.ac ‚!git add -A && git commit‘

Danach kann man git add und auch git commit wie folgt ausführen:

git ac -m „message“

Fazit

Man kann Git praktisch überall verwenden. Es ist schnell, unabhängig, zeitgemäß und sehr sicher. Allerdings braucht es ein gewisses Know-how, um sich zu Beginn damit zurechtzufinden. Wenn man es einmal beherrscht, macht es große Freude, damit zu arbeiten. In vielen Bereichen verschafft es Erleichterung und Zeitersparnis. Auch wenn es nicht immer einen reibungslosen Ablauf gewährleistet, wiegen die vielen Vorteile, die Git bietet, kleinere Schwierigkeiten allemal auf.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -