Datenschutzerklärung

Git ist heute die mit Abstand beliebteste Versionsverwaltung und hat Subversion längst diesen Rang abgelaufen. Trotzdem setzen viele Teams immer noch Subversion ein und scheuen aus verschiedenen Gründen den Umstieg. Wir wollen mit diesem Beitrag die Unterschiede zwischen Git und Subversion beleuchten und zeigen, unter welchen Voraussetzungen ein Umstieg sinnvoll und was dabei zu beachten ist.

Client-Server oder verteilte Versionsverwaltung

Subversion ist eine zentrale Versionsverwaltung, die nach dem Client-Server-Prinzip arbeitet. Das Repository (also das Archiv mit allen Versionen der Quellen und der gesamten Historie) befindet sich auf einem Server, auf den Arbeitsstationen der Entwickler werden nur die aktuellen Versionen der Dateien im Repository und lokale Änderungen an diesen gespeichert. Um eine Änderung in die Versionsverwaltung zu bringen, müssen wir diese im zentralen Repository speichern. Ebenso müssen wir alle Informationen über die Historie von Dateien aus dem zentralen Repository holen, da sie lokal nicht vorhanden sind. Für das Arbeiten mit Subversion ist deshalb praktisch immer der Zugriff zum zentralen Repository erforderlich.

Git ist eine verteilte Versionsverwaltung, d.h. an jedem Arbeitsplatz existiert ein Repository, das die aktuelle Version und die Historie der verwalteten Dateien enthält. Die Arbeit geschieht zunächst immer auf dem lokalen Repository. Sollen Änderungen ausgestauscht werden, erfolgt dies indem die betreffenden Repositories miteinander abgeglichen werden. Dazu können wir ein oder mehrere remote zugängliche Repositories einrichten, die dann gemeinsam vom Team benutzt werden. Für die meisten Arbeitsschritte mit Git benötigen wir lediglich das lokale Repository, der Zugriff auf Remote-Repositories ist nur für einen Abgleich nötig. Grundsätzlich besteht hinsichtlich der Struktur der verschiedenen Git-Repositories totale Freiheit - wir empfehlen aber, sich hinsichtlich dieser Frage an bewährten Git-Workflows zu orientieren.

Branches und Tags

Da das Einchecken von Änderungen in Subversion stets auf dem zentralen Repository erfolgt und aus dessen Sicht eine atomare Operation ist, gibt es zu jedem Zeitpunkt nur eine Version des Repositories. Dessen Historie verläuft deshalb linear, jede Version hat genau einen Vorgänger. Branches und Tags der verwalteten Quellen werden in Subversion in Form von Verzeichnissen innerhalb des Repositories angelegt, in die existierende Pfade kopiert werden. Ein Merge zwischen Branches ist also ein Merge des Inhalts verschiedener Verzeichnisse im Repository. Wenn wir inzwischen Verzeichnisse umbenannt oder gar Verzeichnisstukturen geändert haben, kommt es beim Merge in Subversion häufig zu Problemen. Deshalb werden Branches in Subversion eher zurückhaltend und mit kurzer Lebensdauer (zum Beispiel für Stabilisierungsphasen) eingesetzt.

Der zentrale Begriff in Git ist das Commit-Objekt, das entsteht wenn eine neue Version in das Repository eingestellt wird. Da Git von verteilten Repositories ausgeht, können aus Git-Sicht gleichzeitig mehrere Commit-Objekte existieren. Jedes Commit-Objekt und damit jede Version kann also einen oder mehrere Vorgänger haben. Branches und Tags sind in Git nichts anderes als Referenzen auf Commit-Objekte, ein Merge ist immer ein Merge der Versionen, die den beteiligten Commit-Objekten im Repository entsprechen. Das Ergebnis eines Merge ist ein neues Commit-Objekt mit den beiden gemergten als Vorgänger. Tree-Conflicts wie bei Subversion können beim Merge in Git nicht auftreten. Das Mergen von Branches gehört in Git zum normalen Alltag und ist häufig beim Abgleich des lokalen in ein gemeinsames Repository erforderlich. Der Umgang mit Branches ist in Git mühelos, die meisten Git-Workflows beinhalten Branching-Modelle.

Performance

Da viele Operationen wie der Blick in die Historie von Dateien oder der Vergleich verschiedener Versionen in Git keinen Zugriff auf Remote-Repositories benötigen, entfallen die von Subversion bekannten Wartezeiten - Git ermöglicht ein flüssigeres Arbeiten. Auch die meisten Aufgaben, für die ein Zugriff auf das zentrale Repository erforderlich ist, sind mit geringeren Wartezeiten verbunden als in Subversion.

Große Dateien

Subversion speichert im Repository die Historie von Dateien in Form von Deltas ab - unabhängig davon, ob es sich um Textdateien oder binäre Dateien handelt. Dagegen speichert Git immer die kompletten Versionen einer Datei ab. Für die Ablage sehr großer Dateien (z.B. Filme oder Firmwareimages) ist Subversion deshalb Git deutlich überlegen, sowohl was die Übertragungszeiten als auch den Speicherverbrauch betrifft. Als verteilte Versionsverwaltung verfügt Git auch nicht über die Möglichkeit, Dateien zu locken. Locking ist im Umgang mit großen Binärdateien aber sinnvoll, da Änderungen hier in der Regel nicht gemerged werden können. Generell vermeiden wir es deshalb in Git große Binärdateien mit den Sourcecode zu verwalten und greifen dafür besser auf geeignete Artefaktrepositories zurück.

Benutzerrechte

Als serverbasiertes System beinhaltet Subversion die Möglichkeit, Zugriffsrechte auf der Ebene von Pfaden und einzelnen Dateien im Repository zu vergeben. Die Notwendigkeit dazu ergibt sich allerdings vor allem dadurch, dass Subversion Tags und Branches als Pfade im Repository speichert. Bei unsachgemäßer Handhabung ist es z.B. möglich den Inhalt von Tags versehentlich zu verändern.

Da Git auf verteilten Repositories beruht, ist die Vergabe von Zugriffsrechten innerhalb eines Repositories nicht vorgesehen. Git behandelt Branches und Tags nicht als Pfade innerhalb des Repositories, somit besteht auch nicht Notwendigkeit für eine derartige Rechtevergabe wie in Subversion. Git-Backends wie Gerrit, Bitbucket oder GitLab bieten uns darüber hinaus ausgeklügelte Möglichkeiten, Benutzerrechte passend zum Workflow zu vergeben.

Was beim Unstieg zu berücksichtigen ist

Die Subversion Community ist definitiv im Schrumpfen begriffen. Wir beobachten, dass die Unterstützung von Git in anderen Entwicklertools deutlich inzwischen besser als die von Subversion ist. Inzwischen ist damit zu rechnen, dass neue Kollegen eher Erfahrung mit Git als mit Subversion haben und das Arbeiten mit Subversion zurecht als Rückschritt betrachten.

Hat man ein funktionierendes Konfigurationsmanagement auf der Basis von Subversion, besteht natürlich nicht die Notwendigkeit sofort auf Git umzusteigen. Der Umstieg auf Git ist immer auch mit Änderungen in der Entwicklungsmethodik verbunden und will deshalb gut vorbereitet sein. Außerdem muss ausreichend Zeit für einen Umstieg eingeplant werden!

Fazit

Git ist Subversion im Hinblick auf Funktionalität und Performance klar überlegen. Dieses mehr an Möglichkeiten bringt allerdings auch eine etwas höhere Komplexität mit sich. Um erfolgreich mit Git zu arbeiten müssen wir dessen grundlegende Konzepte und Mechanismen verstanden haben. Ebenso ist es erforderlich einem zur eigenen Arbeitsweise passenden Git-Workflow zu folgen.
Ein guter Einstieg in den Umstieg auf Git gelingt mit unserem Training Versionsmanagement mit Git

 

Jetzt Kontakt aufnehmen!