Hier ist eine Kopie einer Antwort, die ich auf eine doppelte Frage gegeben habe, die seitdem über Git vs. SVN (September 2009) gelöscht wurde .
Besser? Abgesehen von dem üblichen Link WhyGitIsBetterThanX unterscheiden sie sich:
Eines ist ein zentrales VCS, das auf einer billigen Kopie für Zweige und Tags basiert. Das andere (Git) ist ein verteiltes VCS, das auf einem Diagramm von Revisionen basiert. Siehe auch Kernkonzepte von VCS .
Dieser erste Teil erzeugte einige falsch informierte Kommentare, die vorgaben, dass der grundlegende Zweck der beiden Programme (SVN und Git) der gleiche ist, dass sie jedoch ganz unterschiedlich implementiert wurden.
Um den grundlegenden Unterschied zwischen SVN und Git zu verdeutlichen , möchte ich Folgendes umformulieren:
SVN ist die dritte Implementierung einer Revisionskontrolle : RCS, dann CVS und schließlich SVN Verzeichnisse von versionierten Daten verwalten. SVN bietet VCS-Funktionen (Beschriften und Zusammenführen), aber sein Tag ist nur eine Verzeichniskopie (wie ein Zweig, außer dass Sie nichts in einem Tag-Verzeichnis "berühren" sollen), und sein Zusammenführen ist immer noch kompliziert und basiert derzeit auf Meta -Daten hinzugefügt, um sich daran zu erinnern, was bereits zusammengeführt wurde.
Git ist eine Dateiinhaltsverwaltung (ein Tool zum Zusammenführen von Dateien), die zu einem echten Versionskontrollsystem entwickelt wurde , das auf einer DAG ( Directed Acyclic Graph ) von Commits basiert , bei der Verzweigungen Teil des Datenverlaufs sind (und keine Daten selbst) ) und wo Tags echte Metadaten sind.
Zu sagen, dass sie sich nicht "grundlegend" unterscheiden, weil man dasselbe erreichen, dasselbe Problem lösen kann, ist auf so vielen Ebenen ... einfach falsch.
- Wenn Sie viele komplexe Zusammenführungen haben, ist die Ausführung mit SVN länger und fehleranfälliger. Wenn Sie viele Zweige erstellen müssen, müssen Sie diese verwalten und zusammenführen, was mit Git wiederum viel einfacher ist als mit SVN, insbesondere wenn eine große Anzahl von Dateien beteiligt ist (die Geschwindigkeit wird dann wichtig).
- Wenn Sie teilweise Zusammenführungen für eine laufende Arbeit haben, nutzen Sie den Git-Staging-Bereich (Index), um nur das festzuschreiben, was Sie benötigen, den Rest zu verstauen und in einem anderen Zweig fortzufahren.
- Wenn Sie eine Offline-Entwicklung benötigen ... mit Git sind Sie immer "online", mit Ihrem eigenen lokalen Repository, unabhängig vom Workflow, den Sie mit anderen Repositorys verfolgen möchten.
Trotzdem bestanden die Kommentare zu dieser alten (gelöschten) Antwort darauf:
VonC: Sie verwechseln grundlegende Unterschiede in der Implementierung (die Unterschiede sind sehr grundlegend, da sind wir uns beide einig) mit unterschiedlichen Zielen.
Beide Tools werden für den gleichen Zweck verwendet: Aus diesem Grund konnten viele Teams, die früher SVN verwendet haben, es recht erfolgreich zugunsten von Git ablegen.
Wenn sie nicht dasselbe Problem lösen würden , würde diese Substituierbarkeit nicht existieren.
, worauf ich antwortete:
"Substituierbarkeit" ... interessanter Begriff ( in der Computerprogrammierung verwendet ).
Natürlich ist Git kaum ein Subtyp von SVN.
Sie können mit beiden die gleichen technischen Funktionen (Tag, Verzweigung, Zusammenführen) erzielen, aber Git steht Ihnen nicht im Weg und ermöglicht es Ihnen, sich auf den Inhalt der Dateien zu konzentrieren , ohne über das Tool selbst nachzudenken.
Sie können SVN sicherlich nicht (immer) einfach durch Git ersetzen, "ohne die wünschenswerten Eigenschaften dieses Programms zu ändern (Korrektheit, ausgeführte Aufgabe, ...)" (was auf die oben genannte Substituierbarkeitsdefinition verweist ):
- Eines ist ein erweitertes Revisionstool, das andere ein echtes Versionskontrollsystem.
- Eines eignet sich für kleine bis mittlere monolithische Projekte mit einfachem Zusammenführungsworkflow und (nicht zu vielen) parallelen Versionen. SVN reicht für diesen Zweck aus, und Sie benötigen möglicherweise nicht alle Git-Funktionen.
- Das andere ermöglicht mittlere bis große Projekte, die auf mehreren Komponenten basieren ( ein Repo pro Komponente ), mit einer großen Anzahl von Dateien, die zwischen mehreren Zweigen in einem komplexen Zusammenführungsworkflow zusammengeführt werden sollen, parallelen Versionen in Zweigen, Nachrüstzusammenführungen usw. Sie könnten es mit SVN tun, aber mit Git sind Sie viel besser dran.
SVN kann einfach kein Projekt jeder Größe mit einem Zusammenführungsworkflow verwalten. Git kann.
Auch hier ist ihre Natur grundlegend anders (was dann zu einer unterschiedlichen Implementierung führt, aber das ist nicht der Punkt).
Einer sieht die Revisionskontrolle als Verzeichnisse und Dateien, der andere sieht nur den Inhalt der Datei (so sehr, dass leere Verzeichnisse nicht einmal in Git registriert werden!).
Das allgemeine Endziel mag dasselbe sein, aber Sie können sie nicht auf die gleiche Weise verwenden oder dieselbe Problemklasse (in Umfang oder Komplexität) lösen.