Die Git-Revolution - JAXenter
Vom Klonen und Pushen in verteilten Welten

Die Git-Revolution

Michael Johann

Eine Revolution ist der Gegenbegriff zur Evolution, bei der sich eine Weiterentwicklung vollzieht, während bei einer Revolution immer eine plötzliche Neuerung oder Umkehr von Altbekanntem gemeint ist. Revolutionen finden heutzutage im umgangssprachlichen Sinne meist unter Anwendung von Gewalt statt, beispielsweise bei der Ablösung einer politischen Macht. Was für eine Revolution das verteilte Versionskontrollsystem Git ausgelöst hat, lesen Sie auf den folgenden Seiten.

Wenn Sie in Projekten mit mehr als einem Entwickler gearbeitet haben, ist die Wahrscheinlichkeit relativ groß, dass Sie bereits mit einem Versionskontrollsystem gearbeitet haben. Ich selbst habe im Laufe meiner doch schon etwas langen Karriere so ziemlich alle gängigen Systeme benutzt. Hierzu zählen Folgende:

  • Microsoft VSS
  • CVS
  • Subversion
  • Rational ClearCase
  • Git
  • Mercurial

Weitere Systeme, die das fortgeschrittene Alter eines Softwareveteranen verraten können, sind RCS und SCCS. Alle Systeme haben ihre Vor- und Nachteile, wobei allerdings die Nachteile bei einigen insbesondere älteren und proprietären Systemen überwiegen. Die einfache Nachführung von Änderungen an Dateien beherrschen alle Systeme. Lediglich wenn es zu komplizierten Branch- und Merge-Vorgängen kommt, trennt sich spätestens die Spreu vom Weizen. Grundsätzlich sollten Sie ein Versionskontrollsystem nach Ihrem Bedarf auswählen. Wenn Sie auf nur einem lokalen Rechner und für sich allein arbeiten, reichen Systeme mit weniger Funktionsumfang völlig aus. Features wie verteilte Repositories sind dann eher für Entwickler gedacht, die in größeren Teams mit unterschiedlichen Standorten arbeiten. Zudem unterstützen einige Systeme das Halten von lokalen Repositories, die bei Bedarf in einem zentralen Repository zusammengeführt werden können.

Die besten Versionskontrollsysteme sind auch für alle wichtigen Betriebssysteme verfügbar und oft sogar als Open-Source-Projekte angelegt. Die Integration in die bekannten Entwicklungsumgebungen und die Bereitstellung von Kommandozeilenwerkzeugen ist sicherlich auch ein wichtiger Aspekt bei der Auswahl eines geeigneten Systems. In den letzten Jahren sind einige neue Sterne am Himmel der Versionskontrollsysteme aufgetaucht. Hierzu zählen Subversion, Git und Mercurial. Vielleicht haben Sie bereits Subversion im Einsatz gehabt und kennen sich schon gut mit der Funktionsweise aus. Dann wissen Sie, dass Subversion, das sich anschickt, der Nachfolger von CVS zu sein, ein zentrales Repository benötigt, in dem alle Versionen verwaltet werden.

In letzter Zeit aber ist eine Art Social Web für Entwickler entstanden, ganz nach Web-2.0-Manier. Da gibt es Plattformen, die unzählige Projekte hosten und im Sinne der Open-Source-Bewegung Entwickler organisieren und Repositories verwalten. Subversion ist da mit seinem zentralen Ansatz etwas problematisch, denn wer Änderungen einchecken will, muss diese Rechte auch haben und entsprechend verantwortungsvoll handeln. In einer verteilten Welt sind verteilte Repositories ein echter Vorteil, und das ist die eigentliche Revolution hinter Git. Ich habe die Auswirkungen dieser Revolution vor einigen Jahren im Zuge der Nutzung von Ruby on Rails erfahren. Damals war mein Favorit noch Mercurial, das ebenfalls wie Git funktioniert und sehr vielversprechend war. Mit dem Wechsel von Subversion auf Git hatte Ruby on Rails allerdings eine gewisse Richtung vorgegeben. Heute gibt es mit Github (http://www.github.com) eine mächtige Plattform für Entwickler, die einfach nur überzeugt.

Pro und kontra verteilte Versionskontrolle: Vorteile

Sie fragen sich vielleicht, was die Vorteile eines verteilten Repositories sind und warum hier von der Git-Revolution berichtet wird. Die folgenden Vorteile überzeugen schnell von der Sinnhaftigkeit verteilter Repositories.

Höhere Geschwindigkeit: Wenn Sie mit einem zentralisierten Versionskontrollsystem arbeiten, werden alle Änderungen über ein Netzwerk übertragen. Lokale Zugriffe auf ein Repository sind logischerweise wesentlich schneller. Dieser Geschwindigkeitsvorteil ist nicht zu unterschätzen. Wenn Sie beispielsweise ein Subversion Repository mit vielleicht 1000 Dateien initial auschecken, kann dies bei einer DSL-Verbindung schon einige Minuten dauern. Änderungen an 100 Dateien, die zwischen Client und Server ausgetauscht werden müssen, können je nach Umfang ebenfalls lange Zeit in Anspruch nehmen.

Ein verteiltes Versionskontrollsystem muss nur dann über das Netz kommunizieren, wenn Changesets ausgetauscht werden müssen. Alle anderen Arbeiten und auch das Taggen von Versionsständen können bis dahin lokal erfolgen und sind binnen weniger Sekunden erledigt.

Unabhängigkeit vom Netz: Mit einem verteilten Versionskontrollsystem sind Sie bei Arbeiten unterwegs oder an Orten ohne Netzwerkzugriff unabhängig und können trotzdem auf sämtliche Revisionen und die komplette Historie zugreifen. Andere Systeme, die einen zentralisierten Ansatz bieten, sind nicht immer besonders skalierbar, denn der Zugriff von einigen Dutzend Benutzern gleichzeitig kann ein solches System schon mal an seine Leistungsgrenzen führen. Abhilfe schaffen dann Replikationstools, die aber im Grunde nur Geld kosten und das bieten, was Systeme wie Git bereits kostenlos mitbringen.

Merge mit Historie: Subversion ist nicht in der Lage, über die Historie eines Changesets einen Merge vorzunehmen. Benutzer von Subversion müssen jede einzelne Revision eines Branches manuell zusammenführen. Wer dabei den Überblick verliert, endet schnell in einem Chaos aus Konflikten oder fehlenden Teilen.

Wenn Dateien und Verzeichnisse umbenannt wurden, kann Subversion ebenfalls nicht automatisch mergen. Dies ist allerdings auch schon die größte Schwachstelle von Subversion. Der Grund, warum Git hier punktet, ist, dass verteilte Versionskontrollsysteme auf den Prinzipien von Branches und Merges aufbauen.

Pro und kontra verteilte Versionskontrolle: Nachteile

Es gibt nicht nur Vorteile. Damit Sie ein korrektes Bild von einem verteilten Versionskontrollsystem wie Git erhalten, sollen auch die Nachteile kurz erläutert werden. Diese Nachteile können Sie dann vermeiden.

Keine „aktuellste“ Version: Aufgrund der Peer-to-Peer-Architektur existiert keine zentral abrufbare „aktuelleste Version“. Diese lässt sich aber herstellen, wenn alle Lieferanten in ein „zentrales“ Repository pushen. Damit ist ein Repository gemeint, das als zentrales Repository fungiert.

Kein Backup: Auch wenn es ein zentrales Repository gibt, ist es dennoch nicht gleichzeitig ein Backup. Denn wenn Änderungen erst zu spät veröffentlicht werden, ist nicht klar, was damit geschehen soll. Ein zentrales Repository, wie im Abschnitt zuvor beschrieben, hilft hier. Reguläre Backups dieses Systems sollten trotz allem natürlich regelmäßig erfolgen.

Komplexe Versionsnummern: Weil ein verteiltes Versionskontrollsystem keine einheitlichen Versionsnummern über verschiedene Repositories halten kann, gibt es stattdessen einen GUID (Globally Unique Identifier), der beispielsweise bei Git folgendermaßen aussieht: ee632c122bd8f13eb1e885ff230453bddfa772a1.

Wenn zwei Kollegen sich also abstimmen und Versionsnummern austauschen, wird es schon eher schwierig, sich an diese lange Nummer zu erinnern. Daher ist es möglich, Tags zu vergeben, die Menschen wieder einfacher verstehen. Git ist für längere Versionsnummern bekannt, die praktisch niemand mit einem Blick unterscheiden kann. Daher ist eine gute Unterstützung durch Werkzeuge sinnvoll.

Geschrieben von
Michael Johann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.