svn - Warum ist Git besser als Subversion?

Translate

Ich habe benutztSubversionfür ein paar Jahre und nach GebrauchSourceSafeIch liebe Subversion einfach. Kombiniert mitTortoiseSVNIch kann mir nicht wirklich vorstellen, wie es besser sein könnte.

Es gibt jedoch eine wachsende Anzahl von Entwicklern, die behaupten, dass Subversion Probleme hat und dass wir auf die neue Generation verteilter Versionskontrollsysteme umsteigen sollten, wie zGit.

Wie verbessert Git Subversion?

This question and all comments follow the "Attribution Required."

Alle Antworten

Translate

Git ist nicht besser als Subversion. Ist aber auch nicht schlimmer. Es ist anders.

Der Hauptunterschied besteht darin, dass es dezentralisiert ist. Stellen Sie sich vor, Sie sind ein Entwickler unterwegs, entwickeln auf Ihrem Laptop und möchten eine Quellcodeverwaltung, damit Sie 3 Stunden zurückgehen können.

Mit Subversion haben Sie ein Problem: Das SVN-Repository befindet sich möglicherweise an einem Ort, den Sie nicht erreichen können (in Ihrem Unternehmen, und Sie haben derzeit kein Internet). Sie können keine Festschreibung vornehmen. Wenn Sie eine Kopie Ihres Codes erstellen möchten, müssen Sie ihn buchstäblich kopieren / einfügen.

Mit Git haben Sie dieses Problem nicht. Ihre lokale Kopie ist ein Repository, und Sie können sich darauf festlegen und alle Vorteile der Quellcodeverwaltung nutzen. Wenn Sie die Verbindung zum Haupt-Repository wiederherstellen, können Sie sich dagegen festlegen.

Das sieht auf den ersten Blick gut aus, aber denken Sie an die zusätzliche Komplexität dieses Ansatzes.

Git scheint das "neue, glänzende, coole" Ding zu sein. Es ist keineswegs schlecht (es gibt einen Grund, warum Linus es schließlich für die Linux-Kernel-Entwicklung geschrieben hat), aber ich habe das Gefühl, dass viele Leute in den Zug "Distributed Source Control" einsteigen, nur weil er neu ist und von Linus Torvalds geschrieben wurde, ohne ihn tatsächlich zu verwenden zu wissen warum / ob es besser ist.

Subversion hat Probleme, aber auch Git, Mercurial, CVS, TFS oder was auch immer.

Bearbeiten:Diese Antwort ist jetzt ein Jahr alt und generiert immer noch viele positive Stimmen. Deshalb dachte ich, ich werde noch einige Erklärungen hinzufügen. Im letzten Jahr seit dem Schreiben dieses Artikels hat Git viel Schwung und Unterstützung gewonnen, insbesondere seit Websites wie GitHub wirklich in Fahrt gekommen sind. Ich benutze heutzutage sowohl Git als auch Subversion und möchte einige persönliche Einblicke geben.

Erstens kann Git bei der dezentralen Arbeit zunächst sehr verwirrend sein. Was ist eine Fernbedienung? und Wie richte ich das anfängliche Repository richtig ein? Sind zwei Fragen, die am Anfang auftauchen, insbesondere im Vergleich zu SVNs einfachem "svnadmin create", kann Gits "git init" die Parameter --bare und --shared annehmen, was der "richtige" Weg zu sein scheint, eine Zentralisierung einzurichten Repository. Es gibt Gründe dafür, aber es erhöht die Komplexität. Die Dokumentation des Befehls "checkout" ist für Leute, die umsteigen, sehr verwirrend - der "richtige" Weg scheint "git clone" zu sein, während "git checkout" die Zweige zu wechseln scheint.

Git leuchtet WIRKLICH, wenn Sie dezentralisiert sind. Ich habe einen Server zu Hause und einen Laptop unterwegs, und SVN funktioniert hier einfach nicht gut. Mit SVN kann ich keine lokale Quellcodeverwaltung haben, wenn ich nicht mit dem Repository verbunden bin (Ja, ich kenne SVK oder Möglichkeiten zum Kopieren des Repos). Bei Git ist das sowieso der Standardmodus. Es ist jedoch ein zusätzlicher Befehl (git commit schreibt lokal fest, während git push origin master den Master-Zweig auf die Fernbedienung mit dem Namen "origin" schiebt).

Wie oben gesagt: Git erhöht die Komplexität. Zwei Modi zum Erstellen von Repositorys: Auschecken vs. Klonen, Festschreiben vs. Push ... Sie müssen wissen, welche Befehle lokal und welche mit "dem Server" funktionieren (ich gehe davon aus, dass die meisten Leute immer noch ein zentrales "Master-Repository" mögen). ).

Außerdem ist das Tooling zumindest unter Windows immer noch unzureichend. Ja, es gibt ein Visual Studio AddIn, aber ich verwende immer noch git bash mit msysgit.

SVN hat den Vorteil, dass es VIEL einfacher zu erlernen ist: Es gibt Ihr Repository, alle Änderungen daran, wenn Sie wissen, wie man erstellt, festschreibt und auscheckt, und Sie bereit sind, Dinge wie Verzweigung, Aktualisierung usw. später aufzunehmen auf.

Git hat den Vorteil, dass es VIEL besser geeignet ist, wenn einige Entwickler nicht immer mit dem Master-Repository verbunden sind. Außerdem ist es viel schneller als SVN. Und nach allem, was ich höre, ist die Verzweigungs- und Zusammenführungsunterstützung viel besser (was zu erwarten ist, da dies die Hauptgründe sind, warum sie geschrieben wurde).

Dies erklärt auch, warum es im Internet so viel Aufsehen erregt, da Git perfekt für Open Source-Projekte geeignet ist: Fork es einfach, übertrage deine Änderungen auf dein eigenes Fork und fordere dann den ursprünglichen Projektbetreuer auf, deine Änderungen abzurufen. Mit Git funktioniert das einfach. Probieren Sie es wirklich auf Github aus, es ist magisch.

Was ich auch sehe, sind Git-SVN-Bridges: Das zentrale Repository ist ein Subversion-Repo, aber Entwickler arbeiten lokal mit Git und die Bridge überträgt ihre Änderungen dann auf SVN.

Aber auch mit dieser langen Ergänzung stehe ich zu meiner Kernbotschaft: Git ist nicht besser oder schlechter, es ist einfach anders. Wenn Sie die Notwendigkeit einer "Offline-Quellcodeverwaltung" haben und bereit sind, zusätzliche Zeit damit zu verbringen, diese zu lernen, ist dies fantastisch. Wenn Sie jedoch eine streng zentralisierte Quellcodeverwaltung haben und / oder Schwierigkeiten haben, die Quellcodeverwaltung einzuführen, weil Ihre Mitarbeiter nicht interessiert sind, dann glänzen die Einfachheit und die hervorragenden Werkzeuge (zumindest unter Windows) von SVN.

Quelle
Translate

Mit Git können Sie praktisch alles offline erledigen, da jeder sein eigenes Repository hat.

Das Erstellen von Zweigen und das Zusammenführen von Zweigen ist wirklich einfach.

Auch wenn Sie keine Festschreibungsrechte für ein Projekt haben, können Sie Ihr eigenes Repository online haben und "Push-Anforderungen" für Ihre Patches veröffentlichen. Jeder, der Ihre Patches mag, kann sie in sein Projekt einbeziehen, einschließlich der offiziellen Betreuer.

Es ist trivial, ein Projekt zu verzweigen, zu ändern und die Bugfixes aus dem HEAD-Zweig weiterhin zusammenzuführen.

Git funktioniert für die Linux-Kernel-Entwickler. Das heißt, es ist sehr schnell (muss es sein) und lässt sich auf Tausende von Mitwirkenden skalieren. Git benötigt außerdem weniger Speicherplatz (bis zu 30-mal weniger Speicherplatz für das Mozilla-Repository).

Git ist sehr flexibel, sehr TIMTOWTDI (es gibt mehr als einen Weg, dies zu tun). Sie können jeden gewünschten Workflow verwenden, und Git wird ihn unterstützen.

Endlich gibt esGitHub, eine großartige Website zum Hosten Ihrer Git-Repositories.

Nachteile von Git:

  • Es ist viel schwieriger zu lernen, weil Git mehr Konzepte und mehr Befehle hat.
  • Revisionen haben keine Versionsnummern wie in Subversion
  • Viele Git-Befehle sind kryptisch und Fehlermeldungen sind sehr benutzerunfreundlich
  • Es fehlt eine gute GUI (wie die großeTortoiseSVN)
Quelle
Translate

Andere Antworten haben die Kernfunktionen von Git (die großartig sind) gut erklärt. Aber es gibt auch so vielewenigMöglichkeiten, wie Git sich besser verhält und mein Leben vernünftiger hält. Hier sind einige der kleinen Dinge:

  1. Git hat einen 'clean'-Befehl. SVN benötigt diesen Befehl dringend, wenn man bedenkt, wie oft zusätzliche Dateien auf Ihrer Festplatte gespeichert werden.
  2. Git hat den Befehl 'bisect'. Es ist schön.
  3. SVN erstellt in jedem einzelnen Ordner SVN-Verzeichnisse (Git erstellt nureiner.git-Verzeichnis). Jedes Skript, das Sie schreiben, und jedes Grep, das Sie ausführen, müssen geschrieben werden, um diese .svn-Verzeichnisse zu ignorieren. Sie benötigen außerdem einen vollständigen Befehl ("svn export"), um eine vernünftige Kopie Ihrer Dateien zu erhalten.
  4. In SVN kann jede Datei und jeder Ordner aus einer anderen Revision oder einem anderen Zweig stammen. Zunächst klingt es schön, diese Freiheit zu haben. Dies bedeutet jedoch, dass es eine Million verschiedene Möglichkeiten gibt, Ihre lokale Kasse komplett zu vermasseln. (Zum Beispiel, wenn "svn switch" zur Hälfte fehlschlägt oder wenn Sie einen falschen Befehl eingeben). Und das Schlimmste ist: Wenn Sie jemals in eine Situation geraten, in der einige Ihrer Dateien von einem Ort und einige von einem anderen stammen, sagt Ihnen der "SVN-Status", dass alles normal ist. Sie müssen "svn info" für jede Datei / jedes Verzeichnis ausführen, um herauszufinden, wie seltsam die Dinge sind. Wenn "git status" Ihnen sagt, dass die Dinge normal sind, können Sie darauf vertrauen, dass die Dinge wirklich normal sind.
  5. Sie müssen SVN mitteilen, wann immer Sie etwas verschieben oder löschen. Git wird es einfach herausfinden.
  6. Das Ignorieren der Semantik ist in Git einfacher. Wenn Sie ein Muster (z. B. * .pyc) ignorieren, wird es für ignoriertalleUnterverzeichnisse. (Aber wenn Sie wirklich etwas für nur ein Verzeichnis ignorieren möchten, können Sie). Mit SVN scheint es keine einfache Möglichkeit zu geben, ein Muster in allen Unterverzeichnissen zu ignorieren.
  7. Ein weiteres Element, bei dem Dateien ignoriert werden. Git ermöglicht es, "private" Einstellungen zu ignorieren (mithilfe der Datei .git / info / exclude), die niemanden betreffen.
Quelle
Translate

"Warum Git besser ist als X."beschreibt die verschiedenen Vor- und Nachteile von Git gegenüber anderen SCMs.

Kurz:

  • Git-TracksInhalt statt Dateien
  • Zweige sind leichtund Zusammenführen isteinfachund ich meinewirklich einfach.
  • Es ist verteilt, im Grunde ist jedes Repository ein Zweig. Meiner Meinung nach ist es viel einfacher, gleichzeitig und gemeinsam zu entwickeln als mit Subversion. Es macht auchofflineEntwicklung möglich.
  • Eslegt keinen Workflow fest, wie gesehen beidie oben verlinkte WebsiteMit Git sind viele Workflows möglich. Ein Workflow im Subversion-Stil kann leicht nachgeahmt werden.
  • Git-Repositories sind vielkleiner in der Dateigrößeals Subversion-Repositorys. Es gibt nur ein ".git" -Verzeichnis im Gegensatz zu Dutzenden von ".svn" -Repositorys (siehe Subversion 1.7 und höher)Verwendet jetzt ein einzelnes Verzeichniswie Git.)
  • DasInszenierungDer Bereich ist fantastisch, er ermöglicht es Ihnen, die Änderungen zu sehen, die Sie festschreiben, teilweise Änderungen festzuschreiben und verschiedene andere Dinge zu tun.
  • Verstauenist von unschätzbarem Wert, wenn Sie eine "chaotische" Entwicklung durchführen oder einfach einen Fehler beheben möchten, während Sie noch an etwas anderem arbeiten (an einem anderen Zweig).
  • Sie könnenGeschichte neu schreiben, das sich hervorragend zum Vorbereiten von Patch-Sets und zum Beheben von Fehlern eignet (VorSie veröffentlichen die Commits)
  • … und einMengeMehr.

Es gibt einige Nachteile:

  • Es gibt noch nicht viele gute GUIs dafür. Es ist neu und Subversion gibt es schon viel länger. Dies ist natürlich, da es einige Schnittstellen in der Entwicklung gibt. Einige gute sindTortoiseGitundGitHub für Mac.
  • Teilweise Auscheckvorgänge / Klone von Repositorys sind derzeit nicht möglich (ich habe gelesen, dass sie sich in der Entwicklung befinden). Es gibt jedoch Unterstützung für Submodule. Git 1.7+ unterstützt spärliche Kassen.
  • Es könnte schwieriger sein zu lernen, obwohl ich dies vor etwa einem Jahr nicht für richtig befunden habe. Git hat kürzlich seine Benutzeroberfläche verbessert und ist recht benutzerfreundlich.

In der einfachsten Verwendung sind Subversion und Git ziemlich gleich. Es gibt keinen großen Unterschied zwischen:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

und

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Wo Git wirklich glänzt, verzweigt sich und arbeitet mit anderen Menschen zusammen.

Quelle
Parker Lee
Translate

Google Tech Talk: Linus Torvalds über Git

http://www.youtube.com/watch?v=4XpnKHJAok8

Die Vergleichsseite des Git-Wikis

http://git.or.cz/gitwiki/GitSvnComparsion

Quelle
Translate

Nun, es ist verteilt. Benchmarks zeigen, dass es erheblich schneller ist (aufgrund seiner verteilten Natur sind Vorgänge wie Unterschiede und Protokolle alle lokal, daher ist es in diesem Fall natürlich unglaublich schneller), und Arbeitsordner sind kleiner (was mich immer noch beeindruckt).

Wenn Sie an Subversion oder einem anderen Client / Server-Revisionskontrollsystem arbeiten, erstellen Sie im Wesentlichen Arbeitskopien auf Ihrem Computer vonAuscheckenÜberarbeitungen. Dies ist eine Momentaufnahme des Repositorys. Sie aktualisieren Ihre Arbeitskopie über Updates und das Repository über Commits.

Mit einer verteilten Versionskontrolle haben Sie keinen Snapshot, sondern die gesamte Codebasis. Willst du einen Unterschied mit einer 3 Monate alten Version machen? Kein Problem, die 3 Monate alte Version befindet sich noch auf Ihrem Computer. Dies bedeutet nicht nur, dass die Dinge viel schneller sind, sondern wenn Sie von Ihrem zentralen Server getrennt sind, können Sie dennoch viele der gewohnten Vorgänge ausführen. Mit anderen Worten, Sie haben nicht nur eine Momentaufnahme einer bestimmten Revision, sondern die gesamte Codebasis.

Sie würden denken, dass Git eine Menge Platz auf Ihrer Festplatte beanspruchen würde, aber nach ein paar Benchmarks, die ich gesehen habe, dauert es tatsächlich weniger. Frag mich nicht wie. Ich meine, es wurde von Linus gebaut, er weiß ein oder zwei Dinge über Dateisysteme, denke ich.

Quelle
Translate

Die wichtigsten Punkte, die ich an DVCS mag, sind folgende:

  1. Sie können kaputte Dinge begehen. Es spielt keine Rolle, weil andere Leute sie erst sehen, wenn Sie sie veröffentlichen. Die Veröffentlichungszeit unterscheidet sich von der Festschreibungszeit.
  2. Aus diesem Grund können Sie häufiger festlegen.
  3. Sie können die vollständige Funktionalität zusammenführen. Diese Funktion wird einen eigenen Zweig haben. Alle Commits dieses Zweigs beziehen sich auf diese Funktionalität. Sie können dies mit einem CVCS tun, jedoch mit DVCS als Standard.
  4. Sie können Ihren Verlauf durchsuchen (herausfinden, wann sich eine Funktion geändert hat)
  5. Sie können einen Pull rückgängig machen, wenn jemand das Haupt-Repository vermasselt hat. Sie müssen die Fehler nicht beheben. Löschen Sie einfach die Zusammenführung.
  6. Wenn Sie eine Quellcodeverwaltung in einem beliebigen Verzeichnis benötigen, gehen Sie wie folgt vor: git init. und Sie können Änderungen vornehmen, rückgängig machen usw.
  7. Es ist schnell (auch unter Windows)

Der Hauptgrund für ein relativ großes Projekt ist die durch Punkt 3 geschaffene verbesserte Kommunikation. Andere sind nette Boni.

Quelle
Christopher Lee
Translate

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

Lesen Sie bitteEntwickeln Sie mit Git ein 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 arbeitenverteiltauf mehreren Maschinen festschreiben und von und zu ihnen ziehen
  2. Ich habe einzentral backup/publicSVN-Repository für andere zum Auschecken
  3. Und sie können Git für sich selbst verwenden
Quelle
Si.
Translate

Alle Antworten hier sind erwartungsgemäß programmiererorientiert. Was passiert jedoch, wenn Ihr Unternehmen die Revisionskontrolle außerhalb des Quellcodes verwendet? Es gibt viele Dokumente, die kein Quellcode sind, die von der Versionskontrolle profitieren und in der Nähe des Codes und nicht in einem anderen CMS leben sollten. Die meisten Programmierer arbeiten nicht isoliert - wir arbeiten für Unternehmen als Teil eines Teams.

Vergleichen Sie vor diesem Hintergrund die Benutzerfreundlichkeit von Subversion und git sowohl bei Client-Tools als auch bei Schulungen. Ich kann kein Szenario sehen, in demirgendeinDas verteilte Revisionskontrollsystem wird einfacher zu bedienen oder einem Nicht-Programmierer zu erklären sein. Ich würde gerne als falsch erwiesen werden, denn dann könnte ich git bewerten und tatsächlich hoffen, dass es von Leuten akzeptiert wird, die eine Versionskontrolle benötigen und keine Programmierer sind.

Selbst dann, wenn das Management mich fragt, warum wir von einem zentralisierten zu einem verteilten Revisionskontrollsystem wechseln sollen, fällt es mir schwer, eine ehrliche Antwort zu geben, da wir sie nicht brauchen.

Haftungsausschluss: Ich habe mich schon früh für Subversion interessiert (um v0.29), daher bin ich offensichtlich voreingenommen, aber die Unternehmen, für die ich seitdem gearbeitet habe, profitieren von meiner Begeisterung, weil ich deren Verwendung gefördert und unterstützt habe. Ich vermute, dass dies bei den meisten Softwareunternehmen der Fall ist. Ich frage mich, wie viele Unternehmen angesichts der vielen Programmierer, die auf den Git-Zug springen, die Vorteile der Versionskontrolle außerhalb des Quellcodes verpassen werden. Selbst wenn Sie separate Systeme für verschiedene Teams haben, verpassen Sie einige der Vorteile, wie die (einheitliche) Integration der Problemverfolgung, während Sie gleichzeitig die Anforderungen an Wartung, Hardware und Schulung erhöhen.

Quelle
Translate

Subversion ist immer noch ein viel häufiger verwendetes Versionskontrollsystem, was bedeutet, dass es eine bessere Werkzeugunterstützung bietet. Sie finden ausgereifte SVN-Plugins für fast alleIDEund es gibt gute Explorer-Erweiterungen (wie TurtoiseSVN). Davon abgesehen muss ich zustimmenMichael: Git ist nicht besser oder schlechter als Subversion, es ist anders.

Quelle
Prima Lee
Translate

Eines der Dinge an SubVersion, die mich ärgern, ist, dass es in jedem Verzeichnis eines Projekts einen eigenen Ordner ablegt, während git nur einen im Stammverzeichnis ablegt. Es ist nichtDasgroße Sache, aber solche kleinen Dinge summieren sich.

Natürlich hat SubVersion Tortoise, was [normalerweise] sehr schön ist.

Quelle
Adair Lee
Translate

David Richards WANdisco Blog über Subversion / GIT

Das Aufkommen von GIT hat eine Reihe von DVCS-Fundamentalisten mit sich gebracht - die "Gitterons" - die alles andere als GIT für Mist halten. Die Gitterons scheinen zu glauben, dass Software-Engineering auf ihrer eigenen Insel stattfindet, und vergessen oft, dass die meisten Unternehmen nicht ausschließlich leitende Software-Ingenieure beschäftigen. Das ist in Ordnung, aber es ist nicht so, wie der Rest des Marktes denkt, und ich bin glücklich, es zu beweisen: GIT hatte auf den letzten Blick weniger als drei Prozent des Marktes, während Subversion in der Region von fünf Millionen Nutzern und ungefähr der Hälfte davon hat der Gesamtmarkt.

Das Problem, das wir sahen, war, dass die Gitterons (billige) Schüsse auf Subversion abfeuerten. Tweets wie „Subversion ist so [langsam / beschissen / restriktiv / riecht nicht gut / sieht mich komisch an] und jetzt habe ich GIT und [alles funktioniert in meinem Leben / meine Frau wurde schwanger / ich habe danach eine Freundin 30 Jahre Versuch / Ich habe sechs Mal am Blackjack-Tisch gewonnen. Du bekommst das Bild.

Quelle
Translate

Git macht auch das Verzweigen und Zusammenführen sehr einfach. Subversion 1.5 hat gerade Merge Tracking hinzugefügt, aber Git ist immer noch besser. Mit Git ist die Verzweigung sehr schnell und günstig. Dies macht das Erstellen eines Zweigs für jedes neue Feature einfacher. Oh- und Git-Repositorys sind im Vergleich zu Subversion sehr effizient mit Speicherplatz.

Quelle
Hazel Lee
Translate

Es geht um die Benutzerfreundlichkeit / Schritte, die erforderlich sind, um etwas zu tun.

Wenn ich ein einzelnes Projekt auf meinem PC / Laptop entwickle, ist Git besser, da es viel einfacher einzurichten und zu verwenden ist. Sie benötigen keinen Server und müssen beim Zusammenführen keine Repository-URLs mehr eingeben.

Wenn es nur 2 Leute wären, würde ich sagen, dass Git auch einfacher ist, weil man einfach voneinander schieben und ziehen kann.

Sobald Sie darüber hinaus sind, würde ich mich für Subversion entscheiden, da Sie zu diesem Zeitpunkt einen "dedizierten" Server oder Standort einrichten müssen.

Sie können dies mit git genauso gut tun wie mit SVN, aber die Vorteile von git werden durch die Notwendigkeit aufgewogen, zusätzliche Schritte zur Synchronisierung mit einem zentralen Server auszuführen. In SVN legen Sie einfach fest. In git musst du git commit und dann git push. Der zusätzliche Schritt wird einfach deshalb ärgerlich, weil Sie am Ende so viel tun.

SVN hat auch den Vorteil besserer GUI-Tools, jedoch scheint das Git-Ökosystem schnell aufzuholen, sodass ich mir langfristig keine Sorgen machen würde.

Quelle
Abigail Lee
Translate

Einfach Githat eine schöne Seite, die die tatsächliche Nutzung von vergleichtGit und SVNDies gibt Ihnen eine Vorstellung davon, was Git im Vergleich zu SVN tun kann (oder leichter tun kann). (Technisch basiert dies auf Easy Git, einem leichten Wrapper über Git.)

Quelle
Clement Lee
Translate

Git und DVCS eignen sich im Allgemeinen hervorragend für Entwickler, die unabhängig voneinander viel codieren, da jeder seinen eigenen Zweig hat. Wenn Sie jedoch eine Änderung von jemand anderem benötigen, muss sie sich zu ihrem lokalen Repo verpflichten und dann muss sie diese Änderung an Sie weiterleiten, oder Sie müssen sie von ihr abziehen.

Meine eigenen Überlegungen lassen mich auch denken, dass DVCS die Qualitätssicherung und das Release-Management erschwert, wenn Sie beispielsweise zentralisierte Releases ausführen. Jemand muss dafür verantwortlich sein, dieses Push / Pull aus dem Repository aller anderen Benutzer auszuführen, Konflikte zu lösen, die zum Zeitpunkt des ersten Festschreibens zuvor gelöst worden wären, dann den Build durchzuführen und dann alle anderen Entwickler ihre Repos neu synchronisieren zu lassen.

All dies kann natürlich mit menschlichen Prozessen angegangen werden; DVCS hat gerade etwas kaputt gemacht, das durch eine zentralisierte Versionskontrolle behoben wurde, um einige neue Annehmlichkeiten zu bieten.

Quelle
Translate

Ich mag Git, weil es Kommunikationsentwicklern von Entwickler zu Entwickler in einem mittleren bis großen Team hilft. Als verteiltes Versionskontrollsystem hilft es Entwicklern durch sein Push / Pull-System, ein Quellcode-Ökosystem zu erstellen, mit dessen Hilfe ein großer Pool von Entwicklern verwaltet werden kann, die an einem einzelnen Projekt arbeiten.

Angenommen, Sie vertrauen 5 Entwicklern und ziehen nur Codes aus ihrem Repository. Jeder dieser Entwickler verfügt über ein eigenes Vertrauensnetzwerk, aus dem er Codes abruft. Daher basiert die Entwicklung auf der Vertrauensstruktur von Entwicklern, bei der die Codeverantwortung von der Entwicklergemeinschaft geteilt wird.

Natürlich gibt es noch andere Vorteile, die in anderen Antworten hier erwähnt werden.

Quelle
Translate

Einige Antworten haben darauf hingewiesen, aber ich möchte zwei Punkte explizit machen:

1) Die Fähigkeit, selektive Commits durchzuführen (z. B.git add --patch). Wenn Ihr Arbeitsverzeichnis mehrere Änderungen enthält, die nicht Teil derselben logischen Änderung sind, macht es Git sehr einfach, ein Commit durchzuführen, das nur einen Teil der Änderungen enthält. Mit Subversion ist es schwierig.

2) Die Fähigkeit, sich zu verpflichten, ohne die Änderung öffentlich zu machen. In Subversion ist jedes Commit sofort öffentlich und somit unwiderruflich. Dies schränkt die Fähigkeit des Entwicklers, "frühzeitig und häufig festzuschreiben", stark ein.

Git ist mehr als nur ein VCS. Es ist auch ein Tool zum Entwickeln von Patches. Subversion ist lediglich ein VCS.

Quelle
Translate

Ich denke, Subversion ist in Ordnung ... bis Sie anfangen zu verschmelzen ... oder etwas Kompliziertes zu tun ... oder etwas zu tun, was Subversion für kompliziert hält (wie Abfragen, um herauszufinden, welche Zweige mit einer bestimmten Datei durcheinander gebracht wurden, wo eine Änderung vorgenommen wurdetatsächlichkommt von, erkennt Kopien & Pasten, etc) ...

Ich bin mit der gewinnenden Antwort nicht einverstanden und sage dasHauptvorteilvon GIT ist Offline-Arbeit - es ist sicherlich nützlich, aber es ist eher ein Extra für meinen Anwendungsfall. SVK kann auch offline arbeiten, aber ich habe keine Frage, in welche ich meine Lernzeit investieren soll.

Es ist nur unglaublich leistungsfähig und schnell und - nachdem man sich an die Konzepte gewöhnt hat - sehr nützlich (ja, in diesem Sinne: benutzerfreundlich).

Weitere Informationen zu einer Zusammenführungsgeschichte finden Sie hier:Verwenden Sie git-svn (oder ähnliches) * nur *, um bei einer svn-Zusammenführung zu helfen?

Quelle
Sigrid Lee
Translate

Dank der Tatsache, dass es nicht ständig mit einem zentralen Server kommunizieren muss, wird so ziemlich jeder Befehl in weniger als einer Sekunde ausgeführt (offensichtlich sind Git Push / Pull / Fetch langsamer, nur weil sie SSH-Verbindungen initialisieren müssen). Das Verzweigen ist viel einfacher (ein einfacher Befehl zum Verzweigen, ein einfacher Befehl zum Zusammenführen)

Quelle
Translate

Ich liebe es absolut, lokale Zweige meines Quellcodes in Git verwalten zu können, ohne das Wasser des zentralen Repositorys zu verwirren. In vielen Fällen werde ich Code vom Subversion-Server auschecken und ein lokales Git-Repository ausführen, um dies zu tun. Es ist auch großartig, dass das Initialisieren eines Git-Repositorys das Dateisystem nicht überall mit einer Reihe nerviger .svn-Ordner verschmutzt.

In Bezug auf die Unterstützung von Windows-Tools beherrscht TortoiseGit die Grundlagen sehr gut, aber ich bevorzuge immer noch die Befehlszeile, es sei denn, ich möchte das Protokoll anzeigen. Ich mag die Art und Weise, wie Tortoise {Git | SVN} beim Lesen von Commit-Protokollen hilft.

Quelle
Rosemary Lee
Translate

Dies ist die falsche Frage. Es ist allzu einfach, sich auf die Warzen von git zu konzentrieren und ein Argument dafür zu formulieren, warum Subversion zumindest für einige Anwendungsfälle angeblich besser ist. Die Tatsache, dass Git ursprünglich als Konstruktionssatz für Versionskontrollen auf niedriger Ebene konzipiert wurde und über eine barocke, auf Linux-Entwickler ausgerichtete Oberfläche verfügt, erleichtert es den heiligen Kriegen, an Bodenhaftung und wahrgenommener Legitimität zu gewinnen. Git-Befürworter schlagen die Trommel mit Millionen von Workflow-Vorteilen, die SVN-Leute für unnötig erklären. Ziemlich bald wird die gesamte Debatte als zentralisiert oder verteilt dargestellt, was den Interessen der Enterprise-SVN-Tool-Community dient. Diese Unternehmen, die in der Regel die überzeugendsten Artikel über die Überlegenheit von Subversion im Unternehmen veröffentlichen, sind abhängig von der wahrgenommenen Unsicherheit von git und der Unternehmensbereitschaft von svn für den langfristigen Erfolg ihrer Produkte.

Aber hier ist das Problem:Subversion ist eine architektonische Sackgasse.

Während Sie git nehmen und ganz einfach einen zentralisierten Subversion-Ersatz erstellen können, obwohl es svn mehr als doppelt so lange gibt, war svn noch nie in der Lage, auch nur das grundlegende Merge-Tracking so gut wie in git zum Laufen zu bringen. Ein Hauptgrund dafür ist die Entwurfsentscheidung, Zweige mit Verzeichnissen gleichzusetzen. Ich weiß nicht, warum sie ursprünglich diesen Weg gegangen sind, es macht sicherlich das teilweise Auschecken sehr einfach. Leider ist es auch unmöglich, die Geschichte richtig zu verfolgen. Jetzt sollten Sie natürlich Konventionen für das Subversion-Repository-Layout verwenden, um Zweige von regulären Verzeichnissen zu trennen, und svn verwendet einige Heuristiken, damit die Dinge für die täglichen Anwendungsfälle funktionieren. Aber all dies ist nur ein Papier über eine sehr schlechte und einschränkende Entwurfsentscheidung auf niedriger Ebene. Die Möglichkeit, ein repository-bezogenes Diff (anstelle eines verzeichnisbezogenen Diff) durchzuführen, ist eine grundlegende und wichtige Funktionalität für ein Versionskontrollsystem und vereinfacht die Interna erheblich, sodass intelligentere und nützliche Funktionen darauf aufgebaut werden können. Sie können sehen, wie viel Aufwand in die Erweiterung der Subversion gesteckt wurde und wie weit sie von der aktuellen Ernte moderner VCS in Bezug auf grundlegende Operationen wie die Auflösung von Zusammenführungen entfernt ist.

Hier ist mein herzlicher und agnostischer Rat für alle, die immer noch glauben, dass Subversion auf absehbare Zeit gut genug ist:

Subversion wird niemals die neueren VCS-Rassen einholen, die aus den Fehlern von RCS und CVS gelernt haben. Es ist eine technische Unmöglichkeit, wenn sie das Repository-Modell nicht von Grund auf umrüsten, aber dann wäre es nicht wirklich svn, oder? Unabhängig davon, wie sehr Sie glauben, nicht über die Fähigkeiten eines modernen VCS zu verfügen, schützt Sie Ihre Unwissenheit nicht vor den Fallstricken der Subversion, von denen viele Situationen unmöglich oder in anderen Systemen leicht zu lösen sind.

Es ist äußerst selten, dass die technische Minderwertigkeit einer Lösung so eindeutig ist wie bei svn. Ich würde sicherlich niemals eine solche Meinung zu win-vs-linux oder emacs-vs-vi abgeben, aber in diesem Fall ist es so Clearcut und Quellcodeverwaltung sind ein so grundlegendes Werkzeug im Arsenal des Entwicklers, dass ich der Meinung bin, dass dies eindeutig angegeben werden muss. Unabhängig von der Anforderung, svn aus organisatorischen Gründen zu verwenden, bitte ich alle svn-Benutzer, sich von ihrem logischen Verstand nicht die falsche Überzeugung aufstellen zu lassen, dass modernere VCS nur für große Open-Source-Projekte nützlich sind. Unabhängig von der Art Ihrer Entwicklungsarbeit sind Sie als Programmierer ein effektiverer Programmierer, wenn Sie lernen, wie Sie besser gestaltete VCS verwenden, sei es Git, Mercurial, Darcs oder viele andere.

Quelle
Translate

Subversion ist sehr einfach zu bedienen. Ich habe in den letzten Jahren nie ein Problem gefunden oder festgestellt, dass etwas nicht wie erwartet funktioniert. Außerdem gibt es viele hervorragende GUI-Tools und die Unterstützung für die SVN-Integration ist groß.

Mit Git erhalten Sie ein flexibleres VCS. Sie können es wie SVN mit einem Remote-Repository verwenden, in dem Sie alle Änderungen festschreiben. Sie können es aber auch meistens offline verwenden und die Änderungen nur von Zeit zu Zeit in das Remote-Repository übertragen. Aber Git ist komplexer und hat eine steilere Lernkurve. Ich habe mich zum ersten Mal auf falsche Filialen festgelegt, Filialen indirekt erstellt oder Fehlermeldungen mit nicht vielen Informationen über den Fehler erhalten und wo ich mit Google suchen muss, um bessere Informationen zu erhalten. Einige einfache Dinge wie das Ersetzen von Markern ($ Id $) funktionieren nicht, aber GIT verfügt über einen sehr flexiblen Filter- und Hook-Mechanismus zum Zusammenführen eigener Skripte. So erhalten Sie alles, was Sie brauchen, und mehr, aber es benötigt mehr Zeit und das Lesen der Dokumentation ;)

Wenn Sie größtenteils offline mit Ihrem lokalen Repository arbeiten, haben Sie keine Sicherung, wenn auf Ihrem lokalen Computer etwas verloren geht. Mit SVN arbeiten Sie meistens mit einem Remote-Repository, das gleichzeitig mit Ihrem Backup auf einem anderen Server ist ... Git kann auf die gleiche Weise funktionieren, aber dies war nicht das Hauptziel von Linus, so etwas wie SVN2 zu haben. Es wurde für die Linux-Kernel-Entwickler und die Anforderungen eines verteilten Versionskontrollsystems entwickelt.

Ist Git besser als SVN? Entwickler, die nur einen Versionsverlauf und einen Sicherungsmechanismus benötigen, haben ein gutes und einfaches Leben mit SVN. Entwickler, die häufig mit Zweigen arbeiten, mehrere Versionen gleichzeitig testen oder größtenteils offline arbeiten, können von den Funktionen von Git profitieren. Es gibt einige sehr nützliche Funktionen wie das Verstauen, die mit SVN nicht gefunden wurden und die das Leben erleichtern können. Auf der anderen Seite werden jedoch nicht alle Menschen alle Funktionen benötigen. Ich kann also die Toten von SVN nicht sehen.

Git benötigt eine bessere Dokumentation und die Fehlerberichterstattung muss hilfreicher sein. Auch die vorhandenen nützlichen GUIs sind nur selten. Dieses Mal habe ich nur 1 GUI für Linux gefunden, die die meisten Git-Funktionen (git-cola) unterstützt. Die Eclipse-Integration funktioniert, ist jedoch nicht offiziell veröffentlicht und es gibt keine offizielle Update-Site (nur einige externe Update-Sites mit regelmäßigen Builds aus dem Trunkhttp://www.jgit.org/updates) Die heutzutage am meisten bevorzugte Art, Git zu verwenden, ist die Befehlszeile.

Quelle
Translate

Eric Sinkfrom SourceGear schrieb eine Reihe von Artikeln über Unterschiede zwischen verteilten und nicht verteilten Versionskontrollsystemen. Er vergleicht Vor- und Nachteile der gängigsten Versionskontrollsysteme. Sehr interessante Lektüre.
Artikel finden Sie in seinem Blog,www.ericsink.com:

Quelle
Godfery Lee
Translate

Für Leute, die eine gute Git-GUI suchen,Syntevo SmartGitkönnte eine gute Lösung sein. Es ist proprietär, aber für den nichtkommerziellen Gebrauch kostenlos, läuft unter Windows / Mac / Linux und unterstützt SVN sogar mit einer Art Git-SVN-Brücke, denke ich.

Quelle
Simona Lee
Translate

http://subversion.wandisco.com/component/content/article/1/40.html

Ich denke, es ist ziemlich sicher zu sagen, dass unter Entwicklern die SVN Vs. Das Git-Argument tobt schon seit einiger Zeit, und jeder hat seine eigene Meinung darüber, was besser ist. Dies wurde sogar in den Fragen während unseres Webinars zu Subversion im Jahr 2010 und darüber hinaus angesprochen.

Hyrum Wright, unser Open Source-Direktor und Präsident der Subversion Corporation, spricht über die Unterschiede zwischen Subversion und Git sowie über andere verteilte Versionskontrollsysteme (DVCS).

Er spricht auch über die bevorstehenden Änderungen in Subversion, wie z. B. Working Copy Next Generation (WC-NG), von denen er glaubt, dass sie eine Reihe von Git-Benutzern dazu veranlassen werden, wieder zu Subversion zu konvertieren.

Sehen Sie sich sein Video an und teilen Sie uns Ihre Meinung mit, indem Sie entweder diesen Blog kommentieren oder in unseren Foren posten. Die Registrierung ist einfach und dauert nur einen Moment!

Quelle
Charlotte Lee
Translate

Git in Windows wird jetzt recht gut unterstützt.

Schauen Sie sich GitExtensions = anhttp://code.google.com/p/gitextensions/

und das Handbuch für ein besseres Windows Git-Erlebnis.

Quelle
Translate

Ich habe in letzter Zeit in Git Land gewohnt und ich mag es für persönliche Projekte, aber ich wäre nicht in der Lage, Arbeitsprojekte von Subversion zu wechseln, da sich das Denken der Mitarbeiter geändert hat, ohne dringende Vorteile. Darüber hinaus ist das größte Projekt, das wir intern durchführen, extrem abhängig vonsvn: externalswas nach dem, was ich bisher gesehen habe, in Git nicht so gut und nahtlos funktioniert.

Quelle
Yar
Translate

Erstens scheint die gleichzeitige Versionskontrolle ein leicht zu lösendes Problem zu sein. Es ist überhaupt nicht. Wie auch immer...

SVN ist nicht intuitiv. Git ist noch schlimmer. [sarkastische Spekulation] Dies könnte daran liegen, dass Entwickler, die schwierige Probleme wie die gleichzeitige Versionskontrolle mögen, kein großes Interesse daran haben, eine gute Benutzeroberfläche zu erstellen. [/ sarkastische Spekulation]

SVN-Unterstützer glauben, dass sie kein verteiltes Versionskontrollsystem benötigen.Das habe ich auch gedacht.Aber jetzt, wo wir ausschließlich Git verwenden, bin ich ein Gläubiger. Jetzt funktioniert die Versionskontrolle für mich UND das Team / Projekt, anstatt nur für das Projekt zu arbeiten. Wenn ich einen Zweig brauche, verzweige ich. Manchmal ist es ein Zweig, der einen entsprechenden Zweig auf dem Server hat, und manchmal nicht. Ganz zu schweigen von all den anderen Vorteilen, die ich untersuchen muss (teilweise dank des arkanen und absurden Mangels an Benutzeroberfläche, die ein modernes Versionskontrollsystem ist).

Quelle
Omar Lee
Translate

Warum ich denke, dass Subversion besser ist als Git (zumindest für die Projekte, an denen ich arbeite), hauptsächlich aufgrund seiner Benutzerfreundlichkeit und des einfacheren Workflows:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Quelle