Soll ich SVN oder Git verwenden?

SVN ist ein Repo und viele Kunden. Git ist ein Repo mit vielen Kunden-Repos, jedes mit einem Benutzer. Es ist bis zu einem Punkt dezentralisiert, an dem Benutzer ihre eigenen Bearbeitungen lokal verfolgen können, ohne Dinge auf einen externen Server übertragen zu müssen.

SVN ist zentraler konzipiert, wenn Git darauf basiert, dass jeder Benutzer sein eigenes Git-Repo hat und diese Repos Änderungen wieder in ein zentrales Repo ü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, haben Sie ihr eigenes client - GitHub für Windows ).

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

Möglicherweise benötigen Sie diese Funktionen jedoch noch nicht. Schauen Sie sich die Merkmale, 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, sollten Sie sich an die (derzeit) überlegene Desktop-Integration von SVN halten.

Ich habe dieses Konzept von "git is not good on Windows" 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 erlaubt "Offline-Entwicklung" in einer Weise, wie es Subversion niemals wirklich könnte. Es ist auf fast jeder erdenklichen Plattform verfügbar und verfügt über mehr Funktionen, als Sie wahrscheinlich jemals nutzen werden.

Hier ist eine Kopie einer Antwort, die ich aus einer doppelten Frage gemacht 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 billigen Kopien für Zweige und Tags basiert, das andere (Git) ist ein verteiltes VCS, das auf einem Revisionsdiagramm basiert. Siehe auch Kernkonzepte von VCS .

Dieser erste Teil erzeugte einige falsch informierte Kommentare, in denen behauptet wurde, dass der grundlegende Zweck der beiden Programme (SVN und Git) der gleiche ist, dass sie jedoch sehr unterschiedlich implementiert wurden.
Um den grundlegenden Unterschied zwischen SVN und Git zu verdeutlichen, möchte ich Folgendes umformulieren:

• SVN ist die dritte Implementierung eines Revision Steuerelements : RCS, dann CVS und schließlich SVN Verzeichnisse verwalten versionierter Daten. SVN bietet VCS-Funktionen (Beschriften und Zusammenführen), aber sein Tag ist nur eine Verzeichniskopie (wie eine Verzweigung, außer dass Sie nichts in einem Tag-Verzeichnis "anfassen" sollen), und sein Zusammenführen ist immer noch kompliziert, derzeit basiert es auf Meta -data hinzugefügt, um sich daran zu erinnern, was bereits zusammengeführt wurde.

• Git ist ein File Content Management ​​(ein Tool zum Zusammenführen von Dateien), entwickelt zu einem echten Versionskontrollsystem, basierend auf einer DAG ( Directed Azyklisches Diagramm von Commits, wobei Verzweigungen Teil des Datenverlaufs sind (und keine Daten selbst) und Tags echte Metadaten sind.

Zu sagen, dass sie sich nicht "grundlegend" voneinander unterscheiden, weil Sie dasselbe erreichen, dasselbe Problem lösen können, 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. Dies ist mit Git wesentlich einfacher als mit SVN, insbesondere wenn eine große Anzahl von Dateien betroffen ist (die Geschwindigkeit wird dann wichtig).
• wenn Sie eine teilweise Zusammenführung für eine in Bearbeitung befindliche Arbeit haben, können Sie den Git-Staging-Bereich (Index) nutzen, um nur das festzuschreiben, was Sie benötigen, den Rest zu verstauen und mit einem anderen Zweig fortzufahren.
• wenn Sie eine Offline-Entwicklung benötigen, sind Sie mit Git immer "online" und verfügen über ein eigenes lokales Repository, unabhängig davon, welchen Workflow Sie mit anderen Repositorys verfolgen möchten.

Dennoch 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 ist es vielen Teams, die zuvor SVN verwendet haben, recht erfolgreich gelungen, dieses Tool zugunsten von Git zu verwenden.
Wenn sie nicht dasselbe Problem lösen würden, gäbe es diese Substituierbarkeit nicht.

, auf die ich antwortete:

"Substituierbarkeit" ... interessanter Begriff ( , der in der Computerprogrammierung verwendet wird ).
Natürlich ist Git kaum ein Subtyp von SVN.

Sie können mit beiden die gleichen technischen Funktionen (Tag, Branch, Merge) 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 mit Sicherheit nicht (immer) einfach durch Git ersetzen, "ohne die gewünschten Eigenschaften dieses Programms (Korrektheit, durchgeführte Aufgabe, ...) zu ändern" (dies ist ein Verweis auf die oben genannte Substituierbarkeitsdefinition ):

• Eines ist ein erweitertes Revisionstool, das andere ein echtes Versionskontrollsystem.
• Eines eignet sich für kleine bis mittlere monolithische Projekte mit einfachem Merge-Workflow und (nicht zu vielen) parallelen Versionen. SVN ist für diesen Zweck ausreichend und Sie benötigen möglicherweise nicht alle Git-Funktionen.
• Die andere Option ermöglicht mittlere bis große Projekte, die auf mehreren Komponenten basieren ( ein Repo pro Komponente ), wobei eine große Anzahl von Dateien zwischen mehreren Zweigen in einem komplexen Zusammenführungsworkflow zusammengeführt werden kann, parallele Versionen in Niederlassungen, Nachrüstungszusammenschlüsse und so weiter. Du könntest es mit SVN machen, aber mit Git bist du viel besser dran.
  SVN kann einfach kein Projekt beliebiger Größe mit einem Merge-Workflow verwalten. Git kann.

Wieder ihre Natur ist grundlegend anders (was dann zu einer unterschiedlichen Implementierung führt, aber das ist nicht der Punkt).
Einer sieht die Versionskontrolle als Verzeichnisse und Dateien, der andere sieht nur den Inhalt der Datei (so sehr, dass sich leere Verzeichnisse nicht einmal in Git registrieren!).

Das allgemeine Endziel mag dasselbe sein, aber Sie können sie nicht auf die gleiche Weise verwenden, noch können Sie dieselbe Klasse von Problemen (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 verwalte ich mein Home-Verzeichnis mit SVN. SVN ist das einzige VCS (verteilt oder nicht), das meine TrueCrypt-Dateien nicht beeinträchtigt (bitte korrigieren Sie mich, wenn es ein anderes VCS gibt, das 500 MB + Dateien effektiv verarbeitet). Dies liegt daran, dass Diff-Vergleiche gestreamt werden (dies ist ein sehr wichtiger Punkt). Rsync ist nicht akzeptabel, da es nicht in beide Richtungen funktioniert.

2. Partial Repository (Subdir) Check-Out/Check-In. 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 auf einem anderen Computer von meinem Heimatverzeichnis aus überprüfen 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):

• Das geht unglaublich schnell. Kein anderes SCM, das ich verwendet habe, konnte mithalten, und ich habe viel verwendet, einschließlich Subversion, Perforce, darcs, BitKeeper, ClearCase und CVS.
• Es ist voll verteilt. Der Repository-Besitzer kann nicht vorschreiben, wie ich arbeite. Ich kann Verzweigungen erstellen und Änderungen festschreiben, während die Verbindung zu meinem Laptop unterbrochen 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, per 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.
• Filialen sind sogar billiger als in Subversion. Das Erstellen einer Verzweigung 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 führen Zweige ihre gesamte Geschichte mit. ohne eine fremde Kopie anzufertigen und durch die Kopie zu gehen. Bei der Verwendung von Subversion war es immer umständlich, den Verlauf einer Datei auf einem Zweig zu betrachten, der vor der Erstellung des Zweigs aufgetreten war. von #git: spearce: Ich verstehe nichts über SVN auf der Seite. Ich habe einen Zweig in SVN erstellt und beim Durchsuchen des Verlaufs wurde dem gesamten Verlauf eine Datei im Zweig 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. Das bedeutet, dass beim Zusammenführen von zwei Zweigen weniger Fehler auftreten können.
• Zusammenführungen von Zweigniederlassungen werden als Teil des ordnungsgemäßen Verlaufs des Repositorys aufgezeichnet. Wenn ich zwei Zweige zusammenführe oder wenn ich einen Zweig zurück in den Stamm führe, von 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 es 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 haben eine Speicherkapazität von weniger als 1 MB, da sie nur Vorlesungsnotizen, Hausaufgaben und meine LaTeX-Antworten speichern.
• Die internen Dateiformate des Repositorys sind unglaublich einfach. Dies bedeutet, dass die Reparatur sehr einfach ist, 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 hat. Und ich habe gesehen, wie sich Berkley DB zu oft selbst beschädigt hat, um meinem Code im BDB-Backend von Subversion zu vertrauen.
• 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 rund 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 ich das oben Gesagte gelesen habe.

Ich würde ein Subversion-Repository einrichten. Auf diese Weise können einzelne Entwickler auswählen, ob sie Subversion-Clients oder Git-Clients verwenden möchten (mit git-svn). Mit git-svn bietet Ihnen nicht alle Vorteile einer vollständigen Git-Lösung, aber es gibt einzelnen Entwicklern viel Kontrolle über ihren eigenen Workflow.

Ich glaube, es wird eine 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, wie 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 Git Clone-Befehl darauf zu.

Lesen Sie bitte Entwickeln mit Git in einem Google Code-Projekt

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

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

1. Ich kann verteilt auf mehreren Rechnern arbeiten, festschreiben und von und zu ihnen ziehen
2. Ich habe ein zentrales backup/public SVN-Repository für andere zum Auschecken
3. Und es steht ihnen frei, Git für sich zu nutzen

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

UPDATE: Entschuldigung für den defekten Link, aber ich habe aufgehört, zu versuchen, SO) mit URIs zu arbeiten, die Klammern enthalten. [Link jetzt behoben. -Ed]

Wenn Ihr Team bereits mit Versions- und Versionsverwaltungssoftware wie cvs oder svn vertraut ist, würde ich Ihnen empfehlen, sich für ein einfaches und kleines Projekt (wie Sie behaupten) an SVN zu halten. Ich bin sehr zufrieden mit SVN, aber für das aktuelle E-Commerce-Projekt, das ich auf Django durchführe, habe ich mich entschieden, an Git zu arbeiten (ich verwende Git im SVN-Modus, dh mit einem zentralisierten Repo, zu dem ich Push-to- und Pull-Funktionen ausführe) aus, um mit mindestens einem anderen Entwickler zusammenzuarbeiten). Der andere Entwickler ist mit SVN einverstanden, und obwohl die Erfahrungen anderer unterschiedlich sind, fällt es uns beiden sehr schwer, uns auf dieses kleine Projekt einzulassen. (Wir sind beide Hardcore-Linux-Benutzer, wenn es überhaupt darauf ankommt.)

Ihr Kilometerstand kann natürlich variieren.

Beantworte deine Frage nicht wirklich, aber wenn du die Vorteile von Distributed Revision Control nutzen willst, klingt es so, wie du es tust - und du verwendest Windows, denke ich. ' Verwenden Sie besser Mercurial , als dass Git als Mercurial eine viel bessere Windows-Unterstützung bietet. Mercurial hat auch einen Mac-Port.

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 momentan 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. Momentan würde ich Subversion für die Entwicklung unter Windows vorziehen. In einigen Jahren kann dies irrelevant sein.

Jetzt hat sich die Welt ein bisschen verändert. Git hat jetzt eine gute Implementierung für Windows. Obwohl ich nicht gründlich auf Windows getestet habe (da ich dieses System nicht mehr benutze), 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 (Centralized vs. Distributed und die Überprüfung auf Tool-Unterstü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.

Es kommt darauf an:

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

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

Ich habe SVN für eine lange Zeit verwendet, aber wann immer ich Git verwendete, hatte ich das Gefühl, dass Git viel leistungsfähiger und leichter ist und obwohl ein wenig Lernaufwand erforderlich ist, ist es besser als SVN.

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

In SVN habe ich mich mit Entwicklern befasst, von Anfängern bis zu Experten, 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 kopieren Sie einfach den Ordner und es funktioniert, weil Git nicht in allen Unterordnern .git-Ordner einführt (wie in SVN).

Nachdem ich mich seit langer Zeit viel mit SVN befasst habe, überlege ich mir nun endlich, 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 wie möglich übernommen werden können gewünscht, und schließlich auf einmal in den Zweig auf dem Server verschoben, im Gegensatz zu SVN (wo wir die Änderungen von Zeit zu Zeit im Repository auf dem Server festschreiben müssen).

Wer kann mir bei der Entscheidung helfen, ob ich mich wirklich für Git entscheiden soll?

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 man die Schwelle überschreitet, wenn man aus CVS, SVN-Land kommt.

Ich würde mich wahrscheinlich für Git entscheiden, da es meiner Meinung nach viel leistungsfähiger ist als SVN. Es gibt günstige Code-Hosting-Dienste, die für mich einfach großartig sind - Sie müssen keine Backups oder Wartungsarbeiten durchführen - GitHub ist der naheliegendste Kandidat.

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

Auf YouTube gibt es dazu ein interessantes Video. Es ist von Linus Torvalds selbst: Google Tech Talk: Linus Torvalds auf git

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

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

hast du es versucht Bzr ?

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

SVN scheint unter Windows eine gute Wahl zu sein, wie von anderen Leuten betont.

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

Man muss sich für ein DVCS entscheiden, 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 nächtliche Builds des Projekts auf jeder der Plattformen durchführt.

DVCS bedeutet in der Regel, dass Sie während der Verteilung einen zentralen Server erstellen, auf den Benutzer Änderungen übertragen können.