Warum ist Git besser als Subversion?

08-06-2019
|

Frage

Ich habe mit Subversion für ein paar Jahre und nach der Verwendung SourceSafe, Ich Liebe es einfach, Subversion.Kombiniert mit TortoiseSVN, Ich kann nicht wirklich vorstellen, wie es noch besser werden könnte.

Dennoch gibt es eine wachsende Zahl von Entwicklern, die behaupten, dass Subversion Probleme und wir werden bewegt, um die neue Generation von verteilten Versionskontrollsystemen wie Git.

Wie funktioniert Git verbessern Subversion?

Lösung

Git ist nicht besser als Subversion.Aber auch nicht schlechter.Es ist anders.

Der wesentliche Unterschied ist, dass es dezentral ist.Stellen Sie sich vor Sie sind ein Entwickler auf die Straße, Sie entwickeln auf Ihrem laptop und Sie haben möchten source control, so, dass können Sie gehen zurück 3 Stunden.

Mit Subversion, haben Sie ein Problem:Das SVN-Repository kann in einem Ort, den Sie nicht erreichen können (in Ihrem Unternehmen, und Sie nicht haben internet im moment), kann Sie nicht verpflichten.Wenn Sie möchten, um eine Kopie des Codes, den Sie haben zu buchstäblich kopieren/einfügen.

Mit Git, Sie nicht haben dieses problem.Ihre lokale Kopie eines Repositorys, und Sie Begehen können es und erhalten Sie alle Vorteile des source-control.Wenn Sie wieder die Konnektivität, um das Haupt-repository, kannst du gegen ihn.

Das sieht gut aus auf den ersten, sondern nur im Kopf behalten, die Komplexität dieses Ansatzes.

Git scheint die "neue, glänzende, Coole" Sache.Es ist keineswegs schlecht (es gibt einen Grund, Linus schrieb er für die Entwicklung des Linux-Kernels, nachdem alle), aber ich habe das Gefühl, dass viele Leute springen auf den "Distributed Source Control" - Zug, nur weil es ist neue und ist von Linus Torvalds geschrieben, ohne wirklich zu wissen, warum/ob es besser ist.

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

Edit: Also diese Antwort ist jetzt ein Jahr alt und immer noch erzeugt viele upvotes, also dachte ich, ich werde ein paar mehr Erklärungen.Im letzten Jahr, da dies zu schreiben, Git hat eine Menge an Schwung gewonnen und Unterstützung, insbesondere da Websites wie GitHub wirklich auf den Weg.Ich bin mit beiden Git und Subversion heute und ich möchte einige persönliche Einblicke.

Erste von alle, Git kann wirklich verwirrend auf den ersten, wenn Sie arbeiten dezentral.Was ist remote?und, Wie man richtig das erste repository?zwei Fragen, die kommen am Anfang, vor allem im Vergleich zu SVN ist einfach "svnadmin create", Git ' s "git init" können die Parameter --bare und --shared, welches wohl das "richtige" Möglichkeit zur Einrichtung eines zentralen repository.Es gibt Gründe dafür, aber es erhöht die Komplexität.Die Dokumentation des "checkout" - Befehl ist sehr verwirrend auf Menschen über ändern - der "richtige" Weg zu sein scheint "git clone", während "git checkout" scheint zu wechseln Zweige.

Git WIRKLICH glänzt, wenn Sie dezentral organisiert.Ich habe einen server zu Hause und einen Laptop auf der Straße, und SVN funktioniert einfach nicht gut hier.Mit SVN kann ich nicht lokale Quelle kontrollieren, wenn ich bin nicht mit dem repository verbunden (ja, ich weiß ungefähr, SVK, oder über die Möglichkeiten, kopieren Sie die repo).Mit Git, das ist der Standard-Modus sowieso.Es ist ein extra Befehl, obwohl (git commit-commit lokal, während git push origin master schiebt den master-branch auf den remote mit dem Namen "origin").

Wie oben schon gesagt:Git fügt Komplexität.Zwei Modi der Erstellung von repositories, Check-out vs.clone, commit vs.push...Sie müssen wissen, welche Befehle lokal arbeiten und die Arbeit mit "dem server" (ich gehe davon aus, dass die meisten Menschen immer noch wie ein zentrales "master-repository").

Auch das Werkzeug ist immer noch unzureichend, zumindest unter Windows.Ja, es ist ein Visual Studio-Add-in, aber ich trotzdem mit der git-bash mit msysgit.

SVN hat den Vorteil, dass es VIEL einfacher zu lernen,:Es ist das repository, alle änderungen Richtung, wenn Sie wissen, wie zu erstellen, zu Begehen und Check-out, und Sie sind bereit zu gehen und können pickup Sachen wie Verzweigungen, update etc.später.

Git hat den Vorteil, dass es VIEL besser geeignet, wenn einige der Entwickler nicht immer mit der master-repository.Auch, es ist viel schneller als SVN.Und von dem, was ich höre, verzweigen und Zusammenführen der support ist um einiges besser (das ist zu erwarten, als diese sind die wichtigsten Gründe, warum es geschrieben wurde).

Dies erklärt auch, warum es erhält so viel buzz im Internet, wie Git ist perfekt geeignet für Open-Source-Projekte:Just Fork it, committen Sie Ihre änderungen, um Ihre eigene Gabel, und dann Fragen Sie den original-Projekt-maintainer ziehen Sie Ihre änderungen.Mit Git, das funktioniert.Wirklich, versuchen Sie es auf Github, es ist Magie.

Was ich auch sehen, sind Git-SVN-Brücken:Das zentrale repository ist ein Subversion-repo, aber Entwickler vor Ort die Arbeit mit Git und die Brücke dann schiebt Sie Ihre änderungen SVN.

Aber selbst mit diesem langen Zusatz, dass ich immer noch stehe zu meiner Kernaussage:Git ist nicht besser oder schlechter, es ist einfach anders.Wenn Sie die Notwendigkeit für "Offline-Source-Control" und die Bereitschaft, Sie zu verbringen extra Zeit zu lernen, es ist fantastisch.Aber wenn Sie haben eine streng zentralisierte Quelle Kontrollieren und/oder kämpfen, um einzuführen die Source-Control in die erste Ort weil Ihre Mitarbeiter nicht interessiert sind, dann ist die Einfachheit und hervorragende Werkzeuge (zumindest unter Windows) von SVN Glanz.

Andere Tipps

Mit Git können Sie fast alles tun offline, denn jeder hat sein eigenes repository.

Machen Zweige und Verschmelzung zwischen Zweigen ist wirklich einfach.

Auch wenn Sie keine commit-Rechte für ein Projekt, können Sie immer noch Ihr eigenes repository online und veröffentlichen "drücken Anfragen" für Ihre patches.Jeder, der gerne Ihre patches kann, ziehen Sie Sie in Ihre Projekte, darunter die offiziellen Betreuer.

Es ist trivial zu Gabel ein Projekt, zu ändern und immer noch halten die Verschmelzung in die bugfixes aus dem KOPF Zweig.

Git arbeitet für die Linux-kernel-Entwickler.Das heißt, es ist wirklich schnell, (es muss sein), und die Waage zu tausenden von Mitwirkenden.Git verwendet außerdem weniger Speicherplatz (bis zu 30-mal weniger Platz für das Mozilla-repository).

Git ist sehr flexibel, sehr TIMTOWTDI (Es gibt mehr als einen Weg, es zu tun).Sie können unabhängig von Workflows, die Sie wollen, und Git wird Sie unterstützen.

Schließlich gibt es GitHub, eine große Website für das hosting von Git-repositories.

Nachteile von Git:

es ist viel schwieriger zu lernen, weil Git hat mehr Konzepte und mehr Befehle.
Revisionen nicht haben Versionsnummern wie in der subversion
viele Git-Befehle sind kryptisch, und die Fehlermeldungen sind sehr Benutzer-unfreundlich
es fehlt eine gute GUI (solche wie die großen TortoiseSVN)

Andere Antworten haben einen guten job gemacht zu erklären, die Kern-features von Git (die sind toll).Aber es gibt auch so viele wenig Möglichkeiten, Git verhält sich besser und hält mein Leben mehr gesund.Hier sind einige der kleinen Dinge:

Git hat ein 'clean' - Befehl.SVN dringend braucht dieser Befehl, wenn man bedenkt, wie Häufig es dump zusätzlichen Dateien auf Ihre Festplatte.
Git hat das "halbieren" - Befehl.Es ist schön.
SVN erstellt .svn-Verzeichnisse in jedem einzelnen Ordner (Git schafft nur eine .git-Verzeichnis).Jedes Skript, das Sie schreiben, und jeder grep du tun, müssen so geschrieben sein, ignorieren Sie diese .svn-Verzeichnisse.Sie müssen auch eine ganze Befehl ("svn export") nur um eine gesunde Kopie Ihrer Dateien.
In SVN, die einzelnen Datei-und Ordner können aus einer anderen revision oder Zweig.Zunächst klingt es schön zu haben diese Freiheit.Aber was das eigentlich bedeutet, ist, dass es gibt eine million verschiedene Möglichkeiten, Ihre lokalen checkout-komplett verkorkst.(für Beispiel, wenn "svn switch" nicht halb durch, oder geben Sie einen Befehl falsch).Und das Schlimmste ist:wenn Sie jemals in eine situation kommen, wo Sie einige Ihrer Dateien kommen von einem Ort, und einige von Ihnen von einem anderen, dem "svn status" wird Ihnen sagen, dass alles normal ist.Die Sie tun müssen "svn info" für jede Datei/Verzeichnis um zu entdecken, wie seltsame Dinge.Wenn "git-status", der Ihnen sagt, dass die Dinge normal sind, dann können Sie darauf Vertrauen, dass die Dinge wirklich sind normal.
Sie haben zu sagen, SVN, wenn Sie Sie verschieben oder löschen Sie etwas.Git nur es herauszufinden.
Ignorieren Semantik sind leichter in Git.Wenn Sie ignorieren die ein Muster (wie *.pyc), wird Sie ignoriert alle Unterverzeichnisse.(Aber wenn Sie wirklich wollen, zu ignorieren, etwas für die nur in einem Verzeichnis, können Sie).Mit SVN, es scheint, dass es keine einfache Möglichkeit, zu ignorieren, ein Muster auf allen Unterverzeichnissen ein.
Ein anderes Element mit Dateien ignorieren.Git macht es möglich, "private" ignorieren-Einstellungen (verwenden Sie die Datei .git/info/exclude), die nicht auf jemand anderes.

"Warum Git Besser ist als X"werden die verschiedenen vor-und Nachteile von Git im Vergleich mit anderen SCMs.

Kurz:

Git tracks Inhalt statt-Dateien
Die Zweige sind leicht und Zusammenführen einfach, und ich meine, wirklich einfach.
Es ist verbreitet, im Grunde jedes repository ist ein Zweig.Es ist viel einfacher zu entwickeln, die gleichzeitig und gemeinsam als mit Subversion, meiner Meinung nach.Es macht auch offline Entwicklung möglich.
Es nicht verhängen jede workflow,, wie gesehen auf der oben verlinkten website, es gibt viele workflows möglich mit Git.Eine Subversion-Stil workflow ist einfach nachahmen.
Git-repositories sind viel kleinere Dateigröße als Subversion-Repositorys.Es gibt nur einen ".git" - Verzeichnis, im Gegensatz zu den Dutzenden ".svn-repositories (Hinweis Subversion 1.7 und höher jetzt verwendet ein einzelnes Verzeichnis wie Git.)
Die staging Bereich ist genial, Sie ermöglicht es Ihnen zu sehen, die änderungen, die Sie Begehen,, Begehen, teilweise änderungen und diverse andere Sachen.
Stashing ist von unschätzbarem Wert, wenn Sie tun, "chaotische" Entwicklung, oder wollen einfach nur, um einen Fehler zu beheben, während Sie arbeiten immer noch auf etwas anderes (auf einen anderen Zweig).
Sie können schreiben Sie die Geschichte neu, - das ist großartig für die Zubereitung von patch-sets und fixieren Sie Ihre Fehler (bevor Sie veröffentlichen die commits)
... und eine Menge mehr.

Es gibt einige Nachteile:

Es gibt nicht viele gute GUIs für ihn noch nicht.Es ist neu und Subversion hat es schon viel länger, so dass dies natürlich ist, da es einige Schnittstellen in der Entwicklung.Einige gute sind enthalten TortoiseGit und GitHub für Mac.
~~Partielle checkouts/Klonen von repositories sind derzeit nicht möglich (habe ich gelesen, dass es in der Entwicklung).Es gibt jedoch submodule support.~~ Git 1.7+ unterstützt sparse-checkouts.
Es könnte schwieriger sein, zu lernen, obwohl ich nicht finde, dass dies der Fall ist (über ein Jahr).Git hat kürzlich eine verbesserte Benutzeroberfläche und ist sehr benutzerfreundlich.

In den meisten vereinfachten Verwendungs -, Subversion-und Git sind so ziemlich das gleiche.Es gibt nicht viel Unterschied zwischen:

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

und

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Wo Git es wirklich glänzt, ist der Verzweigung und arbeiten mit anderen Menschen.

Google Tech Talk:Linus Torvalds on git

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

Das Git-Wiki-Vergleich Seite

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

Nun, es ist verteilt.Benchmarks zeigen, dass es wesentlich schneller (aufgrund seiner verteilten Natur, Operationen wie Vergleiche und Protokolle sind alle lokale, so ist es natürlich spürbar schneller-in diesem Fall), und der Arbeitsordner sind kleiner (die immer noch bläst meinen Geist).

Wenn Sie arbeiten, subversion, oder einem anderen client/server revision control system, erstellen Sie im wesentlichen die Arbeit von Kopien auf Ihrem Rechner durch Check-out Revisionen.Dies stellt eine Momentaufnahme in der Zeit, was die repository sieht folgendermaßen aus.Aktualisieren Sie Ihre Arbeitskopie über updates und aktualisieren Sie das repository per verpflichtet.

Mit einer verteilten Versionskontrolle, müssen Sie nicht eine Momentaufnahme, sondern die gesamte Codebasis.Wanna do a diff mit einer 3-Monat alte version?Kein problem, die 3 Monate alte version ist noch auf Ihrem computer.Dies bedeutet nicht nur die Dinge sind viel schneller, aber wenn Sie getrennt von Ihrem zentralen server, können Sie immer noch viele der Operationen, die Sie gewohnt sind.In anderen Worten, Sie haben nicht nur eine Momentaufnahme einer revision, sondern die gesamte Codebasis.

Sie würden denken, dass Git in Anspruch nehmen würde, einen Haufen Speicherplatz auf Ihrer Festplatte, aber von ein paar benchmarks, die ich gesehen habe, tatsächlich erfordert es weniger.Fragen Sie mich nicht, wie.Ich meine, es wurde von Linus, er weiß ein oder zwei Dinge über Dateisysteme, denke ich.

Die wichtigsten Punkte, die ich mag über DVCS sind diejenigen, die :

Sie verpflichten sich, die kaputten Dinge.Es spielt keine Rolle, weil andere Völker sehen Sie nicht, bis Sie veröffentlichen.Veröffentlichen Zeit ist anders als der commit-Zeit.
Denn dieses Sie verpflichten sich, öfter.
Sie können Zusammenführen komplette functionnality.Diese functionnality haben einen eigenen Zweig.Alle commits in dieser Branche wird im Zusammenhang mit dieser functionnality.Sie können tun es mit einem CVCS jedoch mit DVCS Ihre Standard.
Sie können suchen Ihre Geschichte (finden, wenn eine Funktion geändert )
Sie können rückgängig machen, ziehen, wenn jemand Schraube bis das Haupt-repository, die Sie nicht brauchen, um die Fehler zu beheben.Deaktivieren Sie einfach das merge.
Wenn Sie brauchen eine Quelle, die Kontrolle in einem Verzeichnis tun :git init .und Sie Begehen können, Rückgängigmachen von änderungen, etc...
Es ist schnell (auch auf Windows )

Der Hauptgrund für ein relativ großes Projekt ist die Verbesserung der Kommunikation geschaffen, die durch den Punkt 3.Andere sind nette Boni.

Das lustige an der Sache ist:I host Projekte in Subversion-Repos, aber der Zugang zu Ihnen über den Git Klon-Befehl.

Bitte Lesen Sie Entwickeln mit Git auf einem Google-Code-Projekt

Obwohl Google Code nativ spricht Subversion, können Sie ganz einfach mit Git während der Entwicklung.Die Suche nach "git svn", schlägt diese Praxis ist weit verbreitet, und auch wir ermutigen Sie um damit zu Experimentieren.

Verwendung von Git auf einem Svn-Repository gibt mir Vorteile:

Kann ich arbeiten verteilt auf mehrere Maschinen, die Begehung und ziehen aus und zu Ihnen
Ich habe eine zentrale backup/public svn-repository für andere, um zu überprüfen heraus
Und Sie sind frei, verwenden Sie Git für Ihre eigenen

Alle Antworten sind hier, wie erwartet, Programmierer centric, aber was passiert, wenn Ihr Unternehmen verwendet, revision control, die außerhalb des source code?Es gibt viele Dokumente, die nicht in Quellcode, die nutzen aus der Versionsverwaltung, und sollte Leben in der Nähe von code und nicht in einem anderen CMS.Die meisten Programmierer arbeiten nicht isoliert - wir arbeiten für Unternehmen, als Teil eines Teams.

Mit, dass in Geist, zu vergleichen, Benutzerfreundlichkeit, sowohl client-Werkzeuge und Ausbildung, zwischen Subversion und git.Ich kann nicht sehen, ein Szenario, in dem alle distributed revision control system wird einfacher zu nutzen oder erklären einen nicht-Programmierer.Ich würde gerne als falsch erwiesen, denn dann würde ich in der Lage zu beurteilen, git und eigentlich hoffen, dass es angenommen von Menschen, die Versionskontrolle, die nicht-Programmierer.

Selbst dann, wenn Sie gebeten werden, die durch das management, warum sollten wir uns bewegen, von einem zentralisierten zu verteilten Versionsverwaltung, ich wäre hart gedrückt, um eine ehrliche Antwort, weil wir es nicht brauchen.

Haftungsausschluss:Ich wurde interessiert in der Subversion früh auf (um v0.29) so offensichtlich bin ich voreingenommen, aber die Firmen, für die ich gearbeitet habe, für die seit dieser Zeit profitieren Sie von meiner Begeisterung, denn ich habe angeregt und unterstützt Ihre Verwendung.Ich vermute, dies ist, wie es passiert mit den meisten software-Unternehmen.Mit so vielen Programmierern springen auf dem git Zug, ich Frage mich, wie viele Unternehmen gehen zu verpassen, die Vorteile der Verwendung von Versionsverwaltung außerhalb der source-code?Auch wenn Sie haben getrennte Systeme für die verschiedenen teams, verpassen Sie einige der Vorteile, wie (unified) issue-tracking integration, während die Wartung, hardware und Ausbildung Anforderungen.

Subversion ist immer noch eine viel verwendete version-control-system, was bedeutet, dass es hat eine bessere tool-Unterstützung.Sie finden Reifen SVN-plugins für fast jede IDE, und es gibt gute explorer-Erweiterungen erhältlich (wie TurtoiseSVN).Andere als, dass, ich werde Zustimmen Michael:Git ist nicht besser oder schlechter als die Subversion, ist es anders.

Eines der Dinge, über die SubVersion, das ärgert mich, dass es bringt seinen eigenen Ordner, in jedes Verzeichnis des Projekts, in der Erwägung, dass git nur setzt man in das root-Verzeichnis.Es ist nicht dass große Sache, aber kleine Dinge wie das hinzufügen von bis.

Natürlich hat SubVersion Schildkröte, die [in der Regel] sehr schön.

David Richards WANdisco Blog auf Subversion / GIT

Die Entstehung von GIT brachte eine Rasse von DVCS Fundamentalisten, die 'Gitterons'–, dass der glaube alles andere als GIT ist Mist.Die Gitterons scheinen zu denken, software-engineering geschieht auf Ihre eigene Insel und vergessen dabei oft, dass die meisten Organisationen nicht beschäftigen senior software-Ingenieure ausschließlich.Das ist ok, aber es ist nicht, wie der rest des Marktes denkt, und ich bin froh, es zu beweisen:GIT, auf den letzten Blick hatte weniger als drei Prozent des Marktes, während Subversion hat sich in der region von fünf Millionen Nutzer und etwa die Hälfte des gesamten Marktes.

Das problem, das wir sahen, war, dass die Gitterons feuerten (Billig) Schüsse auf Subversion.Tweets wie “Subversion ist so [slow/beschissen/restriktive/nicht gut riechen/schaut bei mir auf eine komische Weise] und jetzt habe ich GIT und [alles funktioniert in meinem Leben/meine Frau Schwanger/ich habe eine Freundin, die nach 30 Jahren von versuchen/ich sechs mal gewann läuft auf dem blackjack-Tisch].Sie erhalten das Bild.

Git macht auch verzweigen und Zusammenführen wirklich einfach.Subversion 1.5 nur Hinzugefügt merge-tracking, aber Git ist noch besser.Mit Git-Verzweigung ist sehr schnell und Billig.Es macht das erstellen einer Verzweigung für jede neue Funktion mehr möglich.Oh, und Git-repositories sind sehr effizient mit Stauraum im Vergleich zu Subversion.

Es ist alles über die einfache Nutzung/Schritte, die erforderlich sind, um etwas zu tun.

Wenn ich bin die Entwicklung einer Einzel-Projekt auf meinem PC/laptop, git besser ist, weil es ist viel einfacher einzurichten und zu verwenden.Sie brauchen keine server, und Sie brauchen nicht zu halten die Eingabe repository-URL ist, wenn Sie verschmilzt.

Wenn es wurden nur 2 Leute, ich würde sagen, dass git ist auch einfacher, da kann man einfach drücken und ziehen Sie aus einander.

Sobald Sie sich darüber hinaus, dass, obwohl, ich würde gehen für subversion, weil an diesem Punkt müssen Sie einen " dedicated server oder Speicherort.

Sie können dies genauso gut mit git mit SVN, aber die Vorteile von git erhalten aufgewogen durch die Notwendigkeit, zusätzliche Schritte zu synchronisieren mit einem zentralen server.In SVN, die Sie Begehen.Bei git müssen Sie git commit, dann git push.Der zusätzliche Schritt wird ärgerlich, ganz einfach, weil Sie am Ende tut es so sehr.

SVN hat auch den Vorteil, besser GUI-tools, aber die git-ökosystem zu sein scheint, fangen sich schnell, also ich würde nicht sorgen über diese, in der langen Begriff.

Einfach Git hat eine schöne Seite, die Gegenüberstellung der tatsächlichen Nutzung Git und SVN das wird Ihnen eine Idee geben, was Git kann (oder leichter) im Vergleich zu SVN.(Technisch gesehen, basiert dies auf Einfache Git, einen leichtgewichtigen wrapper auf top von Git.)

Git und DVCS im Allgemeinen ist großartig für die Entwickler dabei eine Menge Codierung unabhängig voneinander, denn jeder hat seine eigene Filiale.Wenn Sie brauchen eine Veränderung von jemand anderem, aber Sie hat sich zu verpflichten, Ihre lokalen repo und dann muss Sie push, dass die änderungen für Sie, oder Sie müssen ziehen Sie es von Ihr.

Meine eigene Argumentation erinnert mich auch DVCS macht die Dinge schwieriger für QA-und release-management, wenn Sie Dinge tun, wie zentrale releases.Jemand hat die Verantwortung dafür, dass push/pull von allen anderen repository, lösen Konflikte, die gelöst worden sei bei der ersten Begehung der Zeit vor, dann tut das bauen, und dann, dass alle anderen Entwickler re-synchronisieren Sie Ihre repos.

All dies lässt sich mit menschlichen Prozesse, natürlich;DVCS brach gerade etwas, das befestigt war, die durch die zentralisierte Versionskontrolle, um einige neue Annehmlichkeiten.

Ich mag Git, weil es tatsächlich hilft die Kommunikation von Entwickler zu Entwickler auf eine mittlere bis große Teams.Als distributed version control system, das durch seine push - /pull-system, hilft es, die Entwickler zum erstellen einer source-code-eco-system, die hilft zu verwalten, einen großen pool von Entwicklern, die an einem Projekt.

Zum Beispiel sagen Sie, dass Sie Vertrauen zu 5 Entwicklern und ziehen Sie nur die codes aus Ihrem repository.Jeder dieser Entwickler hat eine eigene trust-Netzwerk, von wo aus Sie ziehen codes.Somit ist die Entwicklung beruht auf Vertrauen Stoff-Entwickler-wo-code Verantwortung aufgeteilt wird, die Entwicklung der Gemeinschaft.

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

Ein paar Antworten haben angedeutet, aber ich machen wollen die 2 Punkte explicit:

1) Die Fähigkeit zur selektiven commits (für Beispiel, git add --patch).Wenn Ihr Arbeitsverzeichnis enthält mehrere änderungen, die nicht Teil der gleichen logischen ändern, Git macht es sehr einfach zu machen, ein commit enthält nur einen Teil der änderungen.Mit Subversion ist es schwierig.

2) Die Fähigkeit, zu Begehen, ohne dass die änderung öffentlich.In Subversion, alle Begehen, wird sofort der öffentlichkeit, und damit unwiderruflich.Diese stark schränkt die Fähigkeit der Entwickler "commit early, commit often".

Git ist mehr als nur ein VCS;es ist auch ein Werkzeug für die Entwicklung von patches.Subversion wird lediglich ein VCS.

Ich denke, dass Subversion ist in Ordnung..bis Sie anfangen zu verschmelzen..oder tut etwas kompliziert..oder etwas zu tun Subversion denkt, ist kompliziert (wie tun Abfragen, um herauszufinden, welche Zweige Durcheinander mit einer bestimmten Datei, bei der eine änderung tatsächlich kommt, Erkennung von copy&Pasten, etc.)...

Ich Stimme nicht mit den gewinnen, die Antwort, sagen die wichtigsten Vorteil GIT-offline arbeiten - es ist sicherlich nützlich, aber es ist mehr wie ein extra für meinen Anwendungsfall.SVK offline arbeiten können, auch noch da keine Frage für mich, welches zu investieren, meine Lernzeit in).

Es ist nur, dass es unglaublich kraftvoll und schnell und gut -nachdem immer verwendet, um die Konzepte, die sehr nützlich sind (ja, in diesem Sinne:user friendly).

Für weitere details zu einer Verschmelzung Geschichte, zu sehen :Mit git-svn (oder ähnlich) *nur*, um zu helfen mit einem svn merge?

Dank der Tatsache, dass es keine Notwendigkeit für die Kommunikation mit einem zentralen server ständig, so ziemlich jeder Befehl läuft in weniger als einer Sekunde (natürlich git push/pull/fetch langsamer sind, weil Sie einfach zu initalise SSH-verbindungen).Die Verzweigung ist weitaus einfacher (einem einfachen Befehl Zweig, einen einfachen Befehl merge)

Ich absolut Liebe es, in der Lage zu verwalten die lokalen Filialen von meinem Quellcode in Git ohne trüben Wasser des zentralen repository.In vielen Fällen werde ich Kaufabwicklung code aus dem Subversion-server, und führen Sie einen lokalen Git-repository nur in der Lage sein, dies zu tun.Es ist auch toll, dass initialisieren Sie ein Git-repository nicht verunreinigen, das Dateisystem mit einem Bündel von lästigen .svn-Ordner überall.

Und so weit wie Windows tool-Unterstützung, TortoiseGit behandelt die Grundlagen sehr gut, aber ich immer noch lieber die Befehlszeile, wenn ich das Protokoll einsehen möchten.Ich mag die Art und Weise Schildkröte{Git|SVN}, hilft beim Lesen von commit-Protokollen.

Das ist die falsche Frage zu Fragen.Es ist alles zu einfach, um den Fokus auf git ' s Warzen und formulieren Sie ein argument, warum subversion ist angeblich besser, zumindest für einige Anwendungsfälle.Die Tatsache, dass git wurde ursprünglich als low-level version control construction set und verfügt über eine barocke linux-Entwickler-orientierte Oberfläche macht es einfacher für die Heiligen Kriege zu gewinnen Traktion und wahrgenommene Legitimität.Git Befürworter bang die Trommel mit Millionen von workflow-Vorteile, die svn Jungs verkünden unnötig.Ziemlich bald die ganze Debatte ist gerahmt als zentralisierte vs. verteilte, die dazu dient den Interessen des Unternehmens svn-tool Gemeinschaft.Diese Unternehmen, die in der Regel setzen sich die überzeugendsten Artikel über subversion ist die überlegenheit der in das Unternehmen, sind abhängig von der wahrgenommenen Unsicherheit des git und der enterprise-Bereitschaft der svn für den langfristigen Erfolg Ihrer Produkte.

Aber hier ist das problem: Subversion ist ein architektonisches dead-end.

In der Erwägung, dass die Sie ergreifen können, git und bauen eine zentrale subversion-Ersatz, ziemlich einfach, obwohl Sie mehr als doppelt so lange svn hat nie in der Lage, selbst grundlegende merge-tracking-arbeiten überall in der Nähe als auch in git.Ein Grund für diese design-Entscheidung zu treffen Filialen den gleichen Verzeichnissen.Ich weiß nicht, warum Sie diesen Weg ging ursprünglich, natürlich ist es teilweise Auschecken sehr einfach.Leider macht es auch unmöglich, zu verfolgen die Geschichte richtig.Nun, offensichtlich sind Sie angeblich die Verwendung von subversion-repository-layout zu trennen Filialen von regelmäßigen Verzeichnisse und svn verwendet einige Heuristiken, um die Dinge funktionieren für die tägliche Verwendung.Aber all dies ist nur übertapezieren ist eine sehr schlechte und die Begrenzung der low-level-design-Entscheidung.Zu können, ein tun, ein repository-wise-diff (eher als Verzeichnis-wise diff) ist die grundlegende und kritische Funktionen für ein version control system, und vereinfacht die Interna, die es ermöglichen, intelligentere und nützliche features oben drauf.Sie können sehen, in die Menge von Aufwand, die in die Verlängerung subversion, und doch, wie weit hinter es ist aus der aktuellen Ernte von modernen VCSes in Bezug auf die grundlegenden Operationen wie merge-Auflösung.

Nun, hier ist mein Herz und unabhängige Beratung für alle, die immer noch glaubt Subversion ist gut genug für die absehbare Zukunft:

Subversion wird niemals fangen bis auf die neueren Rassen der VCSes, die gelernt haben aus den Fehlern von RCS und CVS benutzt werden;es ist technisch unmöglich, es sei denn, Sie rüsten das repository-Modell von Grund auf, aber dann würde es sich nicht wirklich svn wäre es?Unabhängig davon, wie viel Sie denken, dass Sie nicht die Fähigkeiten eines modernen VCS, Ihre Unwissenheit wird Sie nicht schützen, von der Subversion Fallstricke, von denen viele Situationen, die nicht oder nur leicht behoben werden, die in anderen Systemen.

Es ist äußerst selten, dass sich die technische Unterlegenheit der Lösung ist so eindeutig, wie es ist, mit svn, natürlich würde ich nie Zustand, wie eine Meinung über win-vs-linux-oder emacs-vs-vi, aber in diesem Fall ist es so klare und source-control ist so ein grundlegendes Werkzeug in der developer ' s arsenal, dass ich das Gefühl es muss eindeutig angegeben werden.Unabhängig von der Anforderung zu verwenden, svn aus organisatorischen Gründen bitte ich alle svn-Benutzer nicht zu lassen, Ihre logischen Verstand konstruieren eine falsche Vorstellung, dass mehr modernen VCSes sind nur sinnvoll bei großen open-source-Projekte.Unabhängig von der Art Ihrer Entwicklung, wenn Sie ein Programmierer sind, werden Sie ein effektiver Programmierer, wenn Sie lernen, wie man besser gestaltet VCSes, ob es Git, Mercurial, Darcs, oder viele andere.

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

Mit Git erhalten Sie einen flexibleren VCS.Sie können es verwenden, auf die gleiche Weise wie SVN mit einem remote-repository, in dem Sie einen commit für alle änderungen.Aber Sie können es auch verwenden, meist offline und drücken Sie nur die änderungen, die von Zeit zu Zeit an das remote-repository.Aber Git ist komplexer und hat eine steilere Lernkurve.Ich fand mich in der ersten Zeit zu Begehen, um falsche Zweigen erstellen von Zweigen indirekt oder Fehlermeldungen erhalten, mit dem nicht viele Informationen über den Fehler und wo muss ich suchen mit Google, um bessere Informationen.Einige einfache Dinge wie substitution Marker ($Id,$) nicht funktioniert, aber GIT hat eine sehr flexible Filter-und Haken-Mechanismus zum Zusammenführen von eigenen scripts und so erhalten Sie alle Dinge, die Sie brauchen, und mehr, aber es braucht mehr Zeit, und Lesen Sie in der Dokumentation ;)

Wenn Sie funktionieren meist offline mit Ihrem lokalen repository, das Sie kein backup haben, falls etwas verloren auf Ihrem lokalen Rechner.Mit SVN-Sie sind meistens die Arbeit mit einem remote-repository, das ist auch gleichzeitig Ihr backup auf einem anderen server...Git kann auf die gleiche Weise funktionieren, aber dies war nicht das Hauptziel von Linus etwas wie SVN2.Es wurde für die Linux-kernel-Entwickler und die Bedürfnisse einer distributed version control system.

Ist Git besser als SVN?Entwickler, die muss nur eine version der Geschichte-und eine backup-Mechanismus haben eine gute und einfache Leben mit SVN.Entwickler arbeiten oft mit Zweigen, testen Sie mehrere Versionen gleichzeitig arbeiten, oder meist offline nutzen die Funktionen von Git.Es gibt einige sehr nützliche Funktionen wie stashing nicht gefunden, die mit SVN, die machen das Leben leichter.Aber auf der anderen Seite, nicht alle Menschen brauchen alle features.Ich kann also nicht sehen, die tote von SVN.

Git braucht eine bessere Dokumentation und die Fehlerberichterstattung muss werden mehr hilfreich.Auch die bestehende nützlich GUIs sind nur selten.Dieses mal habe ich nur 1-GUI für Linux mit Unterstützung der meisten Git-Funktionen (git-cola).Eclipse-integration ist Arbeit, aber seine nicht offiziell veröffentlicht und es ist kein offizieller update-Website (nur auf einigen externen update-site mit regelmäßigen baut aus dem Kofferraum http://www.jgit.org/updates) So ist die am meisten bevorzugte Art der Verwendung von Git diesem Tage ist die Befehlszeile.

Eric Sink von SourceGear schrieb Serie von Artikeln über die Unterschiede zwischen verteilten und verteilte Versionskontrolle-Systeme.Er vergleicht die vor-und Nachteile der beliebtesten Versionsverwaltungen.Sehr interessant zu Lesen.
Artikel finden Sie auf seinem blog www.ericsink.com:

Für Menschen auf der Suche für eine gute Git-GUI, Syntevo SmartGit könnte eine gute Lösung.Mit seiner proprietären, aber kostenlos für nicht-kommerzielle Nutzung, läuft auf Windows/Mac/Linux und unterstützt sogar SVN einige Art von git-svn bridge, denke ich.

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

Ich denke, es ist ziemlich sicher zu sagen, dass unter Entwicklern, die SVN Vs.Git argument wurde tobt seit einiger Zeit, mit den jeder seinen eigenen Blick auf die besser ist.Das war selbst erzogen, in der die Fragen bei unserem Webinar über die Subversion-im Jahr 2010-und darüber Hinaus.

Hyrum Wright, Direktor von Open Source und der Präsident der Subversion Corporation, spricht über die Unterschiede zwischen Subversion und Git, zusammen mit anderen Distributed Version Control Systems (DVCS).

Er spricht auch über die bevorstehenden änderungen in Subversion, wie Arbeitskopie der Nächsten Generation (WC-NG), die er glaubt, wird verursachen eine Reihe von Git-Benutzer zu konvertieren zurück zu Subversion.

Eine Uhr von seinem video und lass uns wissen, was Sie denken, indem Sie entweder die Kommentare auf diesem blog, oder durch eine Veröffentlichung in unseren Foren.Die Registrierung ist einfach und dauert nur ein moment!

Git in Windows ist ziemlich gut unterstützt.

Check out GitExtensions = http://code.google.com/p/gitextensions/

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

Ich habe Wohnung in Git land in letzter Zeit, und ich mag es, für persönliche Projekte, aber ich würde nicht in der Lage sein zu wechseln Projekten arbeiten, um es noch von der Subversion angesichts der Veränderung im denken der erforderlichen Mitarbeiter, ohne drücken Vorteile.Zudem das größte Projekt, wir führen in-Haus ist extrem abhängig von svn:externals was, von dem, was ich bisher gesehen habe, funktioniert nicht so gut und nahtlos in Git.

Erste, concurrent version control scheint ein einfaches problem zu lösen.Es ist überhaupt nicht.Anyway...

SVN ist nicht ganz intuitiv.Git ist noch schlimmer.[sarkastisch-Spekulationen] es könnte sein, weil die Entwickler, die gerne hart Probleme wie concurrent version control, nicht viel Interesse daran, eine gute Benutzeroberfläche.[/sarkastisch-Spekulation]

SVN-Anhänger denken, dass Sie nicht brauchen a distributed version-control Systems. Ich dachte das auch. Aber jetzt, dass wir Git verwenden ausschließlich, ich bin ein Gläubiger.Jetzt version control funktioniert für mich UND das team/Projekt statt nur die für das Projekt arbeiten.Wenn ich einen Zweig I Zweig.Manchmal ist es ein Zweig, der hat einen entsprechenden Zweig auf dem server, und manchmal nicht.Nicht zu vergessen all die anderen Vorteile, die ich ' ll haben zu gehen zu studieren auf (zum Teil Dank des obskuren und absurden Mangel von UI, die ist eine moderne version control system).

Warum ich denke, dass Subversion ist besser als Git (zumindest für die Projekte, an denen ich arbeiten), vor allem aufgrund seiner Benutzerfreundlichkeit und einfacher workflow:

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

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow