Versionskontrollsysteme im Vergleich

Git vs. Subversion (SVN): Welches Versionskontrollsystem sollten Sie nutzen?
1 Kommentar

Git vs. SVN: Die Debatte wird unter Entwicklern hart geführt. Die Entscheidung für ein Versionskontrollsystem hängt von den Bedürfnissen des Teams und des Unternehmens ab. Dieser Artikel beleuchtet die Unterschiede und unterstützt Sie bei der Entscheidungsfindung.

Die Debatte um Git und SVN lässt sich auf einen entscheidenden Punkt runterbrechen: Git ist ein verteiltes Versionskontrollsystem (DVCS) und SVN ein Programm zur zentralen Versionskontrolle. Der Unterschied besteht darin, dass in verteilten Versionskontrollsystemen jeder Entwickler seine eigene lokale Kopie des gesamten Versionsverlaufs hat, während in zentralen Systemen alles nur in einem serverseitigen Projektarchiv gespeichert wird.

Verteilt vs. zentral

Um Änderungen vorzunehmen, öffnet der jeweilige Kollege eine lokale Version der Dateien, die er bearbeiten möchte und übergibt die Änderungen an den zentralen Speicherort. Die größten Vorteile eines verteilten Systems (Git in diesem Fall) sind die Geschwindigkeit lokaler Vorgänge und die verbesserte Zusammenarbeit. Da ein Großteil der Arbeit lokal erfolgt, muss keine konstante Verbindung zu dem Server bestehen, auf dem das zentrale Repository liegt. Im Ergebnis ist ein verteiltes Versionskontrollsystem im Betrieb deutlich schneller.

Da jeder am Projekt beteiligte Kollege den gesamten Versionsverlauf vorliegen hat, können Änderungen untereinander geteilt werden, bevor die Dateien an das zentrale Projektarchiv übergeben werden. Das betrachten wir im folgenden Absatz genauer.

Binärdateien speichern

Große Binärdateien in Git zu speichern ist problematisch, weil jeder Entwickler den vollständigen Änderungsverlauf des Repositorys auf seinen Rechner herunterlädt. Das bedeutet, dass Git Repositories bei jeder hochgeladenen Änderung an einer Datei um die gesamte Dateigröße wachsen. Es gibt allerdings Workarounds für das Speichern großer Binärdateien in Git, obwohl das System selbst nicht gut auf die Arbeit damit ausgelegt ist.

In SVN wird hingegen nur der gerade bearbeitete Zweig auf die individuellen Client-Rechner heruntergeladen, also ausschließlich die letzten Veränderungen am Projekt. Dadurch blähen große Binärdateien das Repository auf den individuellen Arbeitsplätzen nicht so schnell auf wie in Git. Die Checkout-Zeiten sind darum in SVN geringer als in Git, wenn viele Änderungen an Binärdateien vorgenommen wurden.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

Weil SVN also besser mit Binärdateien umgehen kann, ist es besser für Entwickler geeignet, die viele grafische Medienelemente verwalten müssen. Darum haben sich viele Spieleentwickler und Web-Designer für SVN entschieden.

Außerdem gilt SVN häufig als einfacher zu erlernen als Git, sogar für Leute ohne technischen Hintergrund. Die Speicherung großer Binärdateien in irgendeiner Art von Versionskontrollsystem gilt jedoch im Allgemeinen nicht als nachhaltige Lösung. Mit Repository Managementlösungen wie Deveo können diese Dateien in WebDAV Repositories zwar gespeichert und geteilt werden, sodass die Überlastung der Versionskontrolle vermieden wird. Allerdings speichert WebDAV keinen Versionsverlauf dieser Dateien.

Branching

Branching bedeutet in Versionskontrollsystemen, dass eine Kopie des Objekts angelegt wird, an dem Änderungen vorgenommen werden sollen (beispielsweise von einer Datei mit Quellcode). Über solche Branches kann dann an mehreren verschiedenen Versionen des Codes zugleich gearbeitet werden; die Änderungen werden danach über einen sogenannten Merge wieder zusammengeführt. Dadurch können verschiedene Mitarbeiter zur selben Zeit am Projekt arbeiten, ohne damit die Codebasis zu destabilisieren.

Das Konzept der Branches ist ein großes Thema in der Diskussion um Git und SVN. Grundsätzlich gilt Branching in Git als leichter und einfacher als in SVN. Das liegt daran, dass ein Branch in Git eigentlich nur eine Referenz auf einen Commit in einem lokalen Repository ist. Das bedeutet, dass neue Branches in Git leicht erstellt und nach eigenem Ermessen veröffentlicht werden können.

In SVN beruht das Branching auf den Verzeichnissen innerhalb des Repositorys. Branches zusammenzuführen kann in SVN darum zu Problemen führen, wenn Verzeichnisse innerhalb eines Zweigs umbenannt wurden.

Dieses als „Tree Conflict“ bezeichnete Problem kann allerdings vermieden werden, wenn die Zahl der Umbenennungen limitiert wird und Refactorings nur am Hauptzweig (typischerweise dem „Trunk“) vorgenommen werden. SVN arbeitet hier mit der Copy-to-Write-Strategie. Das bedeutet, dass es nicht notwendig ist, eine physische Kopie eines vollständigen Zweigs anzulegen, sodass die Größe der Repositories reduziert wird und dadurch der Zeitaufwand für das Erstellen eines Zweigs sinkt.

Zugriffsrechte kontrollieren

Ein weiteres zentrales Thema in der Diskussion um Git und SVN sind die verschiedenen Ansätze in puncto Zugriffskontrolle. Git geht standardmäßig erst einmal davon aus, dass alle Mitwirkenden eines Projekts die gleichen Rechte haben sollen. Mit SVN können hingegen Lese- und Schreibrechte auf Ebene einzelner Dateien und ganzer Verzeichnisse vergeben werden.

Sicherheit

Mit SVN bleibt der Änderungsverlauf eines Repositorys immer gleich, mit Ausnahme weniger, sehr seltener Sonderfälle. Wer in SVN Änderungen an der Historie eines Repositorys vornehmen möchte, muss Zugang zum zentralen Server haben. Da Git jedoch grundsätzlich verteilt ist, kann jeder jeden Teil der History in der lokalen Kopie des Repositorys ändern. Eine geänderte History des Repositorys hochzuladen, kann zu Problemen führen, wenn die Arbeit von Anderen auf genau diesen Änderungen beruht.

Copyright © The Apache Software Foundation

Copyright © The Apache Software Foundation

Darum wird von Änderungen am Versionsverlauf von geteilten Branches, beispielsweise dem Master, grundsätzlich abgeraten. Es kann sinnvoll sein, einzelne Branches zu schützen, sodass sich niemand daran zu schaffen machen kann. Um diese wünschenswerte Verhaltensweise zu fördern, ist der Master Branch von Git Repositories in Lösungen wie Deveo grundsätzlich geschützt. Sowohl in Git als auch in SVN ist es außerdem sehr empfehlenswert, regelmäßige Backups durchzuführen. Wenn beispielsweise die Festplatte des zentralen SVN-Servers irreparabel beschädigt wird, hat man ohne Backups ein echtes Problem!

In Git wird der gesamte Verlauf des Repositorys „gesichert“, sobald ein Entwickler das Repository auf seinen Computer kopiert. Auch wenn Git also aufgrund seiner verteilten Natur über einen natürlichen Backup-Mechanismus verfügt, ist es dennoch nicht klug, deshalb auf regelmäßige Backups auf dem geteilten Git Server zu verzichten.

Netzwerk-Verbindung

Bei der Arbeit mit Git muss für die meisten Arbeitsschritte keine Verbindung zum Netzwerk bestehen, weil sie lokal durchgeführt werden. Nur für den Upload von Änderungen ins Git Repository ist eine Netzwerkverbindung notwendig. Da außerdem immer der gesamte Versionsverlauf des Projekts kopiert wird, ist eine Verbindung zum Server nicht einmal dann notwendig, wenn man etwas aus einer früheren Version nachschlagen werden soll.

Speicherplatz-Bedarf

Die unterschiedlichen Anforderungen an den Speicherplatz sind ein großer Streitpunkt in der Debatte um Git und SVN. Es gibt allerdings eigentlich gar keinen signifikanten Unterschied hinsichtlich des notwendigen Speicherplatzes für äquivalente Git und SVN Repositories, obwohl SVN Änderungen auf Datei-Level verfolgt, während Git das auf Eben der Repositories macht.

Wenn man jedoch große Binärdateien speichert (was man ja eh nicht tun sollte), können SVN Repositories, wie bereits erwähnt, deutlich kleiner als Git Repositories sein. Das liegt daran, dass der von SVN verwendete xdelat delta Algorithmus sowohl für Binär- als auch für Textdateien angewendet wird.

Intuitive Verwendung

Grundsätzlich gilt SVN als leichter zu erlernen; auch Personen ohne technisches Vorwissen verstehen das System recht schnell. Das primäre User Interface beruht sowohl bei Git als auch bei SVN auf einer Kommandozeile – die Syntax ist für Anfänger auf Git allerdings schwerer zu verstehen. Darum wird SVN häufiger von Nicht-Entwicklern verwendet, die die Versionen von etwas anderem als Code speichern wollen.

Git vs. SVN – was wählen Sie?

Mit diesem Vergleich wollen wir Ihnen eine Hilfe an die Hand geben, um ihren inneren Git vs. SVN-Konflikt zu lösen. Das Ziel war dabei nicht, das bessere System zu benennen. Die Systeme unterscheiden sich zum Teil grundsätzlich voneinander, auch in ihren Workflows. Am Ende des Tages helfen beide Systeme dabei, die Versionsgeschichte des Codes zu speichern.

Dieser Artikel erschien zuerst auf https://deveo.com/git-vs-svn/.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -