Soll ich SVN oder Git verwenden? [geschlossen]

Ich starte ein neues verteiltes Projekt. Soll ich SVN oder Git verwenden und warum?

SVN ist ein Repo und viele Kunden. Git ist ein Repo mit vielen Client-Repos, jedes mit einem Benutzer. Es ist so dezentralisiert, dass Benutzer ihre eigenen Änderungen lokal verfolgen können, ohne Dinge auf einen externen Server übertragen zu müssen.

SVN ist zentraler konzipiert, wobei Git darauf basiert, dass jeder Benutzer sein eigenes Git-Repo hat und diese Repos Änderungen wieder in ein zentrales übertragen. Aus diesem Grund bietet Git Einzelpersonen eine bessere lokale Versionskontrolle.

In der Zwischenzeit haben Sie die Wahl zwischen TortoiseGit , GitExtensions (und wenn Sie Ihr "zentrales" Git-Repository auf github hosten, ihrem eigenen Client - GitHub für Windows ).

Wenn Sie SVN verlassen möchten, sollten Sie Bazaar ein wenig bewerten . Es ist eines der Versionskontrollsysteme der nächsten Generation mit diesem verteilten Element. Es ist nicht wie git POSIX-abhängig, daher gibt es native Windows-Builds und einige leistungsstarke Open-Source-Marken unterstützen es.

Möglicherweise benötigen Sie diese Funktionen jedoch noch nicht einmal. Schauen Sie sich die Funktionen, Vor- und Nachteile der verteilten VCS an . Wenn Sie mehr als SVN-Angebote benötigen, ziehen Sie eines in Betracht. Wenn Sie dies nicht tun, möchten Sie möglicherweise bei der (derzeit) überlegenen Desktop-Integration von SVN bleiben.

Ich habe dieses Konzept von "Git ist unter Windows nicht gut" nie verstanden. Ich entwickle ausschließlich unter Windows und hatte noch nie Probleme mit Git.

Ich würde definitiv Git über Subversion empfehlen; Es ist einfach so viel vielseitiger und ermöglicht eine "Offline-Entwicklung" auf eine Weise, die Subversion niemals wirklich könnte. Es ist auf fast jeder erdenklichen Plattform verfügbar und bietet mehr Funktionen, als Sie wahrscheinlich jemals verwenden werden.

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.

2 Hauptvorteile von SVN, die selten genannt werden:

1. Unterstützung für große Dateien. Zusätzlich zum Code verwende ich SVN, um mein Home-Verzeichnis zu verwalten. SVN ist das einzige VCS (verteilt oder nicht), das meine TrueCrypt-Dateien nicht verschluckt (bitte korrigieren Sie mich, wenn es ein anderes VCS gibt, das Dateien mit mehr als 500 MB effektiv verarbeitet). Dies liegt daran, dass Diff-Vergleiche gestreamt werden (dies ist ein sehr wesentlicher Punkt). Rsync ist nicht akzeptabel, da es nicht in beide Richtungen funktioniert.

2. Auschecken / Einchecken des Teilrepositorys (Unterverzeichnisses). Mercurial und bzr unterstützen dies nicht und die Unterstützung von git ist begrenzt. Dies ist in einer Teamumgebung schlecht, aber von unschätzbarem Wert, wenn ich etwas von meinem Heimverzeichnis aus auf einem anderen Computer auschecken möchte.

Nur meine Erfahrungen.

Nachdem Sie weitere Nachforschungen angestellt und diesen Link überprüft haben: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Einige Auszüge unten):

• Es ist unglaublich schnell. Kein anderes SCM, das ich verwendet habe, konnte damit Schritt halten, und ich habe viel verwendet, einschließlich Subversion, Perforce, Darcs, BitKeeper, ClearCase und CVS.
• Es ist vollständig verteilt. Der Repository-Besitzer kann nicht vorschreiben, wie ich arbeite. Ich kann Zweige erstellen und Änderungen festschreiben, während die Verbindung zu meinem Laptop getrennt ist, und diese später mit einer beliebigen Anzahl anderer Repositorys synchronisieren.
• Die Synchronisierung kann über viele Medien erfolgen. Ein SSH-Kanal über HTTP über WebDAV, über FTP oder durch Senden von E-Mails mit Patches, die vom Empfänger der Nachricht angewendet werden sollen. Ein zentrales Repository ist nicht erforderlich, kann aber verwendet werden.
• Zweige sind sogar billiger als in Subversion. Das Erstellen eines Zweigs ist so einfach wie das Schreiben einer 41-Byte-Datei auf die Festplatte. Das Löschen eines Zweigs ist so einfach wie das Löschen dieser Datei.
• Im Gegensatz zu Subversion tragen Zweige ihre gesamte Geschichte mit sich. ohne eine seltsame Kopie durchführen zu müssen und durch die Kopie zu gehen. Bei der Verwendung von Subversion war es immer umständlich, den Verlauf einer Datei in einem Zweig zu betrachten, der vor dem Erstellen des Zweigs aufgetreten ist. von #git: spearce: Ich verstehe nichts über SVN auf der Seite. Ich habe eine Verzweigung in SVN erstellt und beim Durchsuchen des Verlaufs wurde dem gesamten Verlauf eine Datei in der Verzweigung angezeigt
• Das Zusammenführen von Zweigen ist in Git einfacher und automatischer. In Subversion müssen Sie sich merken, aus welcher Version Sie zuletzt zusammengeführt haben, damit Sie den richtigen Zusammenführungsbefehl generieren können. Git macht das automatisch und macht es immer richtig. Dies bedeutet, dass beim Zusammenführen von zwei Zweigen weniger Fehler auftreten können.
• Zweigstellenzusammenführungen werden als Teil des ordnungsgemäßen Verlaufs des Repositorys aufgezeichnet. Wenn ich zwei Zweige zusammenführe oder wenn ich einen Zweig wieder in den Stamm zusammenführe, aus dem er stammt, wird dieser Zusammenführungsvorgang als Teil des Repostory-Verlaufs als von mir ausgeführt aufgezeichnet und wann. Es ist schwer zu bestreiten, wer die Zusammenführung durchgeführt hat, wenn sie genau dort im Protokoll steht.
• Das Erstellen eines Repositorys ist eine triviale Operation: mkdir foo; cd foo; git init Das war's. Das heißt, ich erstelle heutzutage ein Git-Repository für alles. Ich benutze normalerweise ein Repository pro Klasse. Die meisten dieser Repositorys befinden sich unter 1 MB auf der Festplatte, da sie nur Vorlesungsnotizen, Hausaufgaben und meine LaTeX-Antworten speichern.
• Die internen Dateiformate des Repositorys sind unglaublich einfach. Dies bedeutet, dass Reparaturen sehr einfach durchzuführen sind, aber noch besser, weil es so einfach ist, dass es sehr schwer ist, beschädigt zu werden. Ich glaube nicht, dass jemals jemand ein Git-Repository beschädigt hat. Ich habe gesehen, dass Subversion mit fsfs sich selbst beschädigt. Und ich habe gesehen, dass Berkley DB sich zu oft selbst beschädigt hat, um meinen Code dem BDB-Backend von Subversion anzuvertrauen.
• Das Dateiformat von Git kann Daten sehr gut komprimieren, obwohl es ein sehr einfaches Format ist. Das CVS-Repository des Mozilla-Projekts umfasst ca. 3 GB. Es sind ungefähr 12 GB im fsfs-Format von Subversion. In Git sind es ungefähr 300 MB.

Nachdem ich das alles gelesen habe, bin ich überzeugt, dass Git der richtige Weg ist (obwohl es ein bisschen Lernkurve gibt). Ich habe Git und SVN auch auf Windows-Plattformen verwendet.

Ich würde gerne hören, was andere zu sagen haben, nachdem sie das Obige gelesen haben.

Ich würde ein Subversion-Repository einrichten. Auf diese Weise können einzelne Entwickler wählen, ob sie Subversion-Clients oder Git-Clients (mit git-svn) verwenden möchten . Die Verwendung git-svnbietet Ihnen nicht alle Vorteile einer vollständigen Git-Lösung, bietet jedoch einzelnen Entwicklern ein hohes Maß an Kontrolle über ihren eigenen Workflow.

Ich glaube, es wird relativ kurze Zeit dauern, bis Git unter Windows genauso gut funktioniert wie unter Unix und Mac OS X (seit Sie gefragt haben).

Subversion verfügt über hervorragende Tools für Windows, z. B. TortoiseSVN für die Explorer-Integration und AnkhSVN für die Visual Studio-Integration.

Das Lustige ist: Ich hoste Projekte in Subversion Repos, greife aber über den Befehl Git Clone darauf zu.

Bitte lesen Sie Entwickeln mit Git in einem Google Code-Projekt

Obwohl Google Code nativ Subversion spricht, können Sie Git während der Entwicklung problemlos verwenden. Die Suche nach "git svn" legt nahe, dass diese Praxis weit verbreitet ist, und wir empfehlen Ihnen auch, damit zu experimentieren.

Die Verwendung von Git in einem Svn-Repository bietet mir folgende Vorteile:

1. Ich kann verteilt auf mehreren Maschinen arbeiten, Commits ausführen und von und zu ihnen ziehen
2. Ich habe ein zentrales backup/public SVN-Repository, das andere auschecken können
3. Und sie können Git für sich selbst verwenden

Nicht wirklich Ihre Frage beantworten, aber wenn Sie die Vorteile von wollen verteilten Revisionssteuerung nutzen - es hört sich so an - und Windows verwenden, sollten Sie Mercurial besser verwenden, als Git als Mercurial eine viel bessere Windows-Unterstützung bietet. Mercurial hat auch einen Mac-Port.

Wenn Ihr Team bereits mit Versions- und Quellcodeverwaltungssoftware wie cvs oder svn vertraut ist, würde ich Ihnen für ein einfaches und kleines Projekt (wie Sie es behaupten) empfehlen, sich an SVN zu halten. Ich bin sehr zufrieden mit svn, aber für das aktuelle E-Commerce-Projekt, das ich auf django mache, habe ich beschlossen, an git zu arbeiten (ich verwende git im svn-Modus, dh mit einem zentralisierten Repo, zu dem ich drücke und ziehe von, um mit mindestens einem anderen Entwickler zusammenzuarbeiten). Der andere Entwickler ist mit SVN vertraut, und obwohl die Erfahrungen anderer unterschiedlich sein mögen, haben wir beide eine wirklich schlechte Zeit, Git für dieses kleine Projekt anzunehmen. (Wir sind beide Hardcore-Linux-Benutzer, wenn es überhaupt darauf ankommt.)

Ihr Kilometerstand kann natürlich variieren.

Auf jeden Fall svn, da Windows bestenfalls ein Bürger zweiter Klasse in der Welt von ist git(siehe http://en.wikipedia.org/wiki/Git_(software)#Portability für weitere Details).

UPDATE: Entschuldigung für den defekten Link, aber ich habe es aufgegeben, SO dazu zu bringen, mit URIs zu arbeiten, die Klammern enthalten. [Link jetzt behoben. -ed]

Der Hauptpunkt ist, dass Git ein verteiltes VCS und Subversion ein zentrales ist. Verteilte VCSs sind etwas schwieriger zu verstehen, haben aber viele Vorteile. Wenn Sie diese Vorteile nicht benötigen, ist Subversion möglicherweise die bessere Wahl.

Eine andere Frage ist die Werkzeugunterstützung. Welches VCS wird von den Tools, die Sie verwenden möchten, besser unterstützt?

EDIT: Vor drei Jahren habe ich so geantwortet:

Und Git funktioniert derzeit unter Windows nur über Cygwin oder MSYS . Subversion unterstützte Windows von Anfang an. Da die Git-Lösungen für Windows möglicherweise für Sie funktionieren, kann es zu Problemen kommen, da die meisten Entwickler von Git mit Linux arbeiten und von Anfang an keine Portabilität im Kopf hatten. Im Moment würde ich Subversion für die Entwicklung unter Windows bevorzugen. In einigen Jahren kann dies irrelevant sein.

Jetzt hat sich die Welt ein wenig verändert. Git hat jetzt eine gute Implementierung unter Windows. Obwohl ich unter Windows nicht gründlich getestet habe (da ich dieses System nicht mehr verwende), bin ich ziemlich zuversichtlich, dass alle wichtigen VCS (SVN, Git, Mercurial, Bazaar) jetzt eine ordnungsgemäße Windows-Implementierung haben. Dieser Vorteil für SVN ist weg. Die anderen Punkte (Zentralisiert vs. Verteilt und Überprüfung auf Werkzeugunterstützung) bleiben gültig.

Ich würde mich für SVN entscheiden, da es weiter verbreitet und bekannter ist.

Ich denke, Git wäre besser für Linux-Benutzer.

Git wird unter Windows noch nicht nativ unterstützt. Es ist für Posix-Systeme optimiert. Wenn Sie jedoch Cygwin oder MinGW ausführen, können Sie Git erfolgreich ausführen.

Heutzutage bevorzuge ich Git gegenüber SVN, aber es dauert eine Weile, bis die Schwelle überschritten ist, wenn Sie aus CVS, SVN-Land kommen.

Ich würde wahrscheinlich Git wählen, weil ich denke, dass es viel leistungsfähiger als SVN ist. Es gibt günstige Code-Hosting-Dienste, die für mich einfach großartig funktionieren - Sie müssen keine Backups oder Wartungsarbeiten durchführen - GitHub ist der offensichtlichste Kandidat.

Trotzdem weiß ich nichts über die Integration von Visual Studio und den verschiedenen SCM-Systemen. Ich stelle mir die Integration mit SVN deutlich besser vor.

Ich habe SVN schon lange verwendet, aber wann immer ich Git verwendet habe, hatte ich das Gefühl, dass Git sehr leistungsfähig und leicht ist und zwar ein wenig Lernaufwand erfordert, aber besser als SVN ist.

Was ich bemerkt habe ist, dass jedes SVN-Projekt, wenn es wächst, zu einem sehr großen Projekt wird, wenn es nicht exportiert wird. Wobei das GIT-Projekt (zusammen mit Git-Daten) sehr leicht ist.

In SVN habe ich mich mit Entwicklern vom Anfänger bis zum Experten befasst, und die Anfänger und Fortgeschrittenen scheinen Dateikonflikte einzuführen, wenn sie einen Ordner aus einem anderen SVN-Projekt kopieren, um ihn wiederzuverwenden. Ich denke, in Git kopiert man einfach den Ordner und es funktioniert, weil Git nicht in allen Unterordnern .git-Ordner einführt (wie SVN).

Nachdem ich mich seit langer Zeit viel mit SVN beschäftigt habe, denke ich endlich darüber nach, meine Entwickler und mich auf Git zu verlagern, da es einfach ist, zusammenzuarbeiten und die Arbeit zusammenzuführen. Ein großer Vorteil ist, dass die Änderungen einer lokalen Kopie so viel übernommen werden können gewünscht und dann im Gegensatz zu SVN (wo wir die Änderungen von Zeit zu Zeit im Repository auf dem Server festschreiben müssen) auf einmal in den Zweig auf dem Server verschoben.

Wer kann mir bei der Entscheidung helfen, ob ich wirklich mit Git gehen soll?

Es kommt darauf an:

Wird Ihre Entwicklung linear sein? Wenn ja, sollten Sie bei Subversion bleiben.

Wenn andererseits Ihre Entwicklung nicht linear ist, was bedeutet, dass Sie eine Verzweigung für verschiedene Änderungen erstellen und diese Änderungen dann wieder mit der Hauptentwicklungszeile (Git als Master-Verzweigung bekannt) zusammenführen müssen, dann tut Git dies VIEL mehr für dich.

Hast du es mit Bzr versucht ? ?

Es ist ziemlich gut, Connonical (die Leute, die Ubuntu machen) haben es geschafft, weil sie nichts anderes auf dem Markt mochten ...

Darf ich die Frage erweitern und fragen, ob Git unter MacOS gut funktioniert?

Antwort auf Kommentare: Danke für die Neuigkeiten, ich hatte mich darauf gefreut, es auszuprobieren. Ich werde es zu Hause auf meinem Mac installieren.

Dazu gibt es auf YouTube ein interessantes Video. Es ist von Linus Torwalds selbst: Goolge Tech Talk: Linus Torvalds auf Git

SVN scheint unter Windows eine gute Wahl zu sein, wie andere Leute zeigen.

Wenn einige Ihrer Entwickler GIT ausprobieren möchten, verwendet er möglicherweise immer GIT-SVN, wobei das SVN-Repository in einem GIT-Repository neu erstellt wird. Dann sollte er in der Lage sein, lokal mit GIT zu arbeiten und dann SVN zu verwenden, um seine Änderungen im Hauptrepository zu veröffentlichen.

Sie müssen mit einem DVCS gehen, es ist wie ein Quantensprung in der Quellcodeverwaltung. Persönlich benutze ich Monotone und seine beschleunigte Entwicklungszeit hat kein Ende. Wir verwenden es für Windows, Linux und Mac und es war sehr stabil. Ich habe sogar einen Buildbot, der jeden Abend das Projekt auf jeder der Plattformen erstellt.

Während der Verteilung von DVCS bedeutet dies normalerweise, dass Sie einen zentralen Server erstellen, auf dem die Benutzer Änderungen vornehmen können.