Weswegen
Tippen, um zu suchen
    Esc zum Schließen · Sofortsuche auf der ganzen Website

    Git und TortoiseSVN: Der Unterschied einfach erklärt

    · Weswegen-Redaktion
    Programmierung

    Die Frage „Git oder TortoiseSVN?“ vergleicht zwei Dinge, die nicht auf derselben Ebene liegen. Git ist ein komplettes Versionskontrollsystem. TortoiseSVN ist dagegen nur die grafische Bedienoberfläche für ein anderes System namens Subversion (SVN). Wer das durcheinanderbringt, wählt schnell das falsche Werkzeug — etwa weil er ein zentrales Modell für verteilt hält oder umgekehrt.

    Was genau wird hier verglichen?

    Der ehrliche Vergleich lautet nicht „Git gegen TortoiseSVN“, sondern Git gegen SVN (Subversion) — also zwei Versionskontrollsysteme. TortoiseSVN ist lediglich ein Client, der SVN unter Windows bedienbar macht: Er klinkt sich in den Windows-Explorer ein, legt Statussymbole (grüne Häkchen, rote Ausrufezeichen) über Ihre Datei-Icons und stellt alle Befehle über das Rechtsklick-Kontextmenü bereit. Sie tippen also keine Kommandozeile, sondern klicken.

    Wichtig für die Einordnung: Für Git gibt es das direkte Gegenstück TortoiseGit — dieselbe Explorer-Integration, nur eben für Git statt SVN. Der faire Vergleich ist damit:

    • System: Git (verteilt) vs. SVN (zentral)
    • Windows-Oberfläche: TortoiseGit vs. TortoiseSVN

    Wenn Sie also „Git“ mit „TortoiseSVN“ vergleichen, vergleichen Sie eigentlich das verteilte Modell von Git mit dem zentralen Modell von SVN — und die Bedienung per Kommandozeile mit der Bedienung per Explorer-Kontextmenü. Ob Git ein Versionskontrollsystem (VCS) oder ein Quellcode-Management (SCM) ist, klären wir separat unter Ist Git ein SCM oder VCS?.

    Zentral gegen verteilt — der eigentliche Kernunterschied

    Das ist der Punkt, an dem sich alles Weitere entscheidet.

    SVN ist zentral. Es gibt genau ein „echtes“ Repository auf einem Server. Ihr lokaler Ordner (die Working Copy) enthält nur die Dateien plus eine Referenz auf die Serverversion — nicht die komplette Historie. Für einen Commit, einen Log oder eine Diff gegen ältere Stände brauchen Sie in der Regel Verbindung zum Server.

    Git ist verteilt. Wenn Sie ein Repository klonen, liegt die komplette Historie auf Ihrem Rechner. Commits, Branches, Logs, Diffs, das Zurückspringen auf alte Stände — all das funktioniert offline. Erst zum Austausch mit dem Team (push / pull) brauchen Sie das Netzwerk.

    Ein sichtbares Detail: SVN vergibt fortlaufende, für das ganze Repository gültige Revisionsnummern (r1, r2, r3 …). Git identifiziert jeden Commit über einen Hash wie a1b2c3d. Die SVN-Nummer sagt „der wievielte Stand“, der Git-Hash ist ein eindeutiger Fingerabdruck des Inhalts.

    So sieht die tägliche Arbeit aus

    Typischer Ablauf mit TortoiseSVN

    Sie arbeiten fast ausschließlich über das Rechtsklick-Menü im Explorer:

    1. Rechtsklick → SVN Checkout – legt eine Working Copy vom Server an.
    2. Dateien wie gewohnt bearbeiten (Overlay-Symbole zeigen den Status an).
    3. Rechtsklick → SVN Update – holt die Änderungen der Kollegen.
    4. Rechtsklick → SVN Commit – schickt Ihre Änderungen mit Kommentar direkt an den Server.

    Entscheidend: In SVN veröffentlicht ein Commit die Änderung sofort für alle. Es gibt keine Zwischenstufe zwischen „lokal gespeichert“ und „im gemeinsamen Repository“.

    Typischer Ablauf mit Git

    Git kennt eine Zwischenstufe mehr. Auf der Kommandozeile:

    git clone https://server/projekt.git
# Dateien bearbeiten
git add .                     # Änderungen für den Commit vormerken
git commit -m "Login-Formular korrigiert"   # lokal festschreiben
git pull                      # Team-Änderungen holen
git push                      # eigene Commits veröffentlichen

    Der Unterschied zu SVN: commit schreibt nur lokal fest. Erst push gibt die Arbeit ans Team weiter. Sie können also zehnmal committen, während Sie offline im Zug sitzen, und erst später alles gebündelt hochladen. Wer die Explorer-Bedienung von Tortoise gewohnt ist, installiert statt der Kommandozeile einfach TortoiseGit und bekommt dasselbe Rechtsklick-Menü — nur mit Git-Befehlen. Wie sich dabei pull von fetch unterscheidet, erklärt Was macht git fetch?.

    Branching und Merging

    Hier liegt der praktische Hauptvorteil von Git.

    In Git ist ein Branch nur ein leichter Zeiger auf einen Commit. Einen neuen Zweig anzulegen kostet Millisekunden:

    git checkout -b feature/warenkorb
# ... arbeiten, committen ...
git checkout main
git merge feature/warenkorb

    Deshalb sind kurzlebige Feature-Branches in Git der Normalfall. Das spätere Löschen erledigen Sie in einem Schritt (siehe Git-Branch lokal und remote löschen).

    In SVN ist ein Branch technisch eine Kopie in ein separates Verzeichnis (Konvention: /trunk, /branches, /tags). Über TortoiseSVN geht das per Branch/Tag…. Das funktioniert, wird aber seltener eingesetzt, weil das Zusammenführen divergierender Branches historisch mühsamer war. Neuere SVN-Versionen merken sich Merges zwar über die Eigenschaft svn:mergeinfo, an die Leichtigkeit von Git kommt der Ablauf aber nicht heran.

    Wo SVN weiterhin punktet

    Git ist nicht in jeder Hinsicht überlegen. SVN hat handfeste Stärken:

    • Teil-Auschecken: Mit SVN holen Sie sich gezielt einen Unterordner eines riesigen Repositorys. Git klont standardmäßig alles (Teil-Klone über --filter und sparse-checkout existieren, sind aber Zusatzarbeit).
    • Große Binärdateien: Für Repositories voller Grafiken, Videos oder Design-Dateien kommt SVN oft besser zurecht. In Git braucht man dafür die Erweiterung Git LFS.
    • Einfache Rechtevergabe pro Verzeichnis: SVN kann Zugriffsrechte feingranular pro Pfad steuern — praktisch in großen Organisationen.
    • Fortlaufende Nummern: Manche Teams schätzen die simple, aufsteigende Revisionsnummer gegenüber kryptischen Hashes.

    Deshalb hält sich SVN bis heute in Bereichen wie Spieleentwicklung, Konstruktion oder in etablierten Unternehmens-Setups.

    Wann eignet sich was?

    • Nehmen Sie Git, wenn Sie mit verteilten Teams arbeiten, viel mit Branches experimentieren, offline arbeiten wollen oder Plattformen wie GitHub, GitLab oder Bitbucket nutzen. Für die allermeisten neuen Software-Projekte ist Git heute der Standard.
    • Nehmen Sie SVN (mit TortoiseSVN), wenn ein zentrales Modell erwünscht ist, Sie sehr große Binärdateien verwalten, nur Teile eines Riesen-Repositorys benötigen oder in einer bestehenden SVN-Umgebung mitarbeiten.

    Und wenn Sie die bequeme Explorer-Bedienung von TortoiseSVN vermissen, aber Git nutzen möchten: TortoiseGit gibt Ihnen genau diese Oberfläche für Git.

    Von SVN zu Git migrieren

    Wollen Sie ein bestehendes SVN-Projekt samt Historie zu Git holen, hilft der eingebaute Befehl git svn:

    git svn clone https://server/svn/projekt --stdlayout projekt-git

    --stdlayout setzt voraus, dass Ihr SVN-Repository der üblichen Struktur mit trunk, branches und tags folgt. Für saubere Autoren-Namen (aus SVN-Kürzeln werden „Name “-Einträge) übergeben Sie zusätzlich eine Zuordnungsdatei über --authors-file. Bei sehr großen Historien lohnt sich ein Blick auf das Werkzeug svn2git.

    FAQ

    Ist TortoiseSVN dasselbe wie SVN? Nein. SVN (Subversion) ist das Versionskontrollsystem, TortoiseSVN nur die grafische Windows-Oberfläche dafür. Sie können SVN auch komplett über die Kommandozeile (svn checkout, svn commit …) bedienen — TortoiseSVN macht es lediglich per Rechtsklick im Explorer bequemer.

    Kann ich mit TortoiseSVN auch Git-Repositories bedienen? Nein, TortoiseSVN spricht nur SVN. Für Git gibt es das eigenständige Programm TortoiseGit desselben Projektumfelds — gleiche Bedienlogik, aber für Git-Repositories.

    Ist Git schneller als SVN? Bei alltäglichen Operationen meist ja, weil Commits, Logs und Diffs bei Git lokal ohne Serverzugriff laufen. SVN muss für viele Aktionen den Server kontaktieren. Bei sehr großen Binärdateien oder wenn Sie nur einen kleinen Teil eines riesigen Repositorys brauchen, kann SVN dagegen im Vorteil sein.