Warum ist Git besser als Subversion?

stimmen
393

Ich habe mit Subversion für ein paar Jahre und nach der Verwendung von Source , ich liebe Subversion. In Kombination mit TortoiseSVN , ich kann nicht wirklich vorstellen , wie es besser sein könnte.

Und doch gibt es eine wachsende Zahl von Entwicklern behaupten , dass Subversion Probleme hat und dass wir auf die neue Generation von verteilten Versionskontrollsystemen bewegen, wie Git .

Wie verbessert Git auf Subversion?

Veröffentlicht am 03/08/2008 um 23:38
quelle vom benutzer
In anderen Sprachen...                            


30 antworten

stimmen
548

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

Der wesentliche Unterschied besteht darin, dass es dezentral. Stellen Sie sich ein Entwickler auf der Straße sind, entwickeln Sie auf Ihrem Laptop, und Sie möchten die Quellcodeverwaltung haben, so dass Sie wieder 3 Stunden gehen kann.

Mit Subversion, haben Sie ein Problem: Die SVN-Repository in einer Position sein, können Sie nicht erreichen können (in Ihrem Unternehmen, und Sie haben kein Internet zur Zeit), können Sie nicht begehen. Wenn Sie eine Kopie des Codes machen wollen, müssen Sie buchstäblich kopieren / es einfügen.

Mit Git, haben Sie dieses Problem nicht. Ihre lokale Kopie ist ein Repository, und Sie können begehen und alle Vorteile der Quellcodeverwaltung bekommen. Wenn Sie die Verbindung zum Haupt-Repository wieder, können Sie dagegen begehen.

Das sieht auf den ersten gut, aber nur halten die zusätzliche Komplexität dieses Ansatzes im Auge behalten.

Git scheint das „neue, glänzend, cool“, was zu sein. Es ist keineswegs schlecht (es gibt einen Grund Linus es für den Linux-Kernel-Entwicklung schließlich schrieb), aber ich glaube, dass viele Menschen auf der „Distributed Source Control“ Zug springen, nur weil es neu ist und von Linus Torvalds geschrieben wird, ohne tatsächlich zu wissen, warum / wenn 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 erzeugt noch viele upvotes, so dass ich dachte , ich werde ein paar mehr Erklärungen hinzuzufügen. Im letzten Jahr dieses seit Schreiben hat Git viel Schwung und Unterstützung gewonnen, zumal Websites wie GitHub auszog wirklich. Ich verwende beide Git und Subversion heute und ich möchte einige persönliche Einblicke teilen.

Zunächst einmal kann Git wirklich verwirrend sein, zunächst an, wenn dezentralen Arbeit. Was ist ein Remote? und Wie man richtig setzt das anfängliche Paketdepot? sind zwei Fragen, die die Parameter --bare und --shared können nehmen am Anfang, kommen vor allem im Vergleich zu SVN des einfachen „svnadmin create“, Git „git init“, die eine zentralisierte die „richtige“ Art und Weise einzurichten zu sein scheint Repository. Es gibt Gründe dafür, aber es erhöht die Komplexität. Die Dokumentation der „Kasse“ Befehl ist sehr verwirrend für Menschen Umstellen - die „richtige“ Art und Weise scheint „git clone“, während „git checkout“ scheint zu wechseln Zweige zu sein.

Git wirklich glänzt, wenn Sie dezentralisiert sind. Ich habe einen Server zu Hause und einen Laptop auf der Straße, und SVN einfach nicht gut arbeitet hier. Mit SVN, kann ich nicht lokale Quelle Kontrolle, wenn ich nicht mit dem Repository verbunden (Ja, ich weiß über SVK oder über Möglichkeiten, den Repo zu kopieren). Mit Git, das ist der Standardmodus sowieso. Es ist ein zusätzlicher Befehl obwohl (git commit verpflichtet lokal, während git push origin master den Master-Zweig auf den Remote-Namen „Ursprung“ drücken).

Wie oben gesagt: Git erhöht die Komplexität. Zwei Modi der Erstellung Repositories, Check-out gegen Klon, begehen vs. Push ... Sie müssen wissen, welche Arbeit vor Ort Befehle und die Arbeit mit dem „Server“ (Ich gehe davon aus den meisten Menschen immer noch wie ein zentralen „Master-Repository“ ).

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

SVN hat den Vorteil, dass es viel einfacher ist, zu lernen: Es ist das Repository, um alle Änderungen zu in Richtung zu ihm, wenn Sie wissen, wie zu schaffen, verpflichten und Check-out und Sie sind bereit Pickup Sachen wie Verzweigung zu gehen und können, aktualisieren usw. später auf.

Git hat den Vorteil, dass es viel besser geeignet, wenn einige Entwickler nicht immer auf das Master-Repository verbunden. Außerdem ist es viel schneller als SVN. Und von dem, was ich höre, Verzweigung und Unterstützung Verschmelzung ist viel besser (was zu erwarten ist, da dies die Hauptgründe sind es geschrieben wurde).

Dies erklärt auch, warum es so viel Begeisterung über das Internet gewinnt, wie Git perfekt geeignet für Open-Source-Projekte ist: Just Fork es, begehen Sie Ihre Änderungen an Ihrer eigenen Gabel, und dann das ursprüngliche Projekt Betreuer bitten um Ihre Änderungen zu ziehen. Mit Git, das funktioniert einfach. Wirklich, versuchen Sie es auf Github, es ist Magie.

Was ich auch sehen Git-SVN Bridges: Das zentrale Repository eine Subversion-Repo ist, aber die Entwickler vor Ort arbeiten mit Git und die Brücke dann schiebt ihre Änderungen SVN.

Aber auch mit dieser langen hinaus stehe ich noch von meiner Kernbotschaft: Git ist nicht besser oder schlechter, es ist nur anders. Wenn Sie die Notwendigkeit einer „Offline-Source Control“ haben und die Bereitschaft, etwas mehr Zeit zu lernen, es zu verbringen, ist es fantastisch. Aber wenn man eine streng zentralisierte Quellcodeverwaltung und / oder kämpft Source Control in erster Linie einzuführen, weil Ihre Mitarbeiter nicht daran interessiert sind, dann ist die Einfachheit und hervorragende Werkzeuge (zumindest unter Windows) von SVN Glanz.

Beantwortet am 03/08/2008 um 23:45
quelle vom benutzer

stimmen
145

Mit Git, können Sie praktisch alles offline, weil jeder seine eigene Repository hat.

Herstellung Zweige und Zusammenführung zwischen den Zweigen ist wirklich einfach.

Selbst wenn Sie keine Rechte für ein Projekt engagieren, können Sie Ihr eigenes Repository Online haben und veröffentlichen „Push-Anforderungen“ für Ihre Patches. Jeder, der Ihre Patches mag, kann sie in ihr Projekt, einschließlich der offiziellen Maintainer ziehen.

Es ist trivial, ein Projekt gabeln, ändern, und immer noch hält in den Fehlerbehebung vom HEAD Zweig zu verschmelzen.

Git arbeitet für den Linux-Kernel-Entwickler. Das heißt, es ist wirklich schnell (es muss sein), und skaliert auf Tausende von Mitwirkenden. Git verwendet auch weniger Platz (bis zu 30-mal weniger Platz für die Mozilla-Repository).

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

Schließlich gibt es GitHub , eine tolle Seite für Git - Repositorys Hosting.

Nachteile von Git:

  • es ist viel schwieriger zu erlernen, weil Git mehr Konzepte und mehr Befehle hat.
  • Überarbeitungen Versionsnummern nicht wie in Subversion haben
  • viele Git-Befehle sind kryptisch und Fehlermeldungen sind sehr benutzerunfreundlich
  • es fehlt eine gute grafische Oberfläche (wie die großen TortoiseSVN )
Beantwortet am 04/08/2008 um 01:24
quelle vom benutzer

stimmen
110

Andere Antworten haben einen guten Job zu erklären , die Kernfunktionen von Git getan (die groß sind). Aber es gibt auch so viele kleine Wege , die Git besser verhält und hilft, mein Leben mehr gesund. Hier sind einige der kleinen Dinge:

  1. Git hat einen ‚sauberen‘ Befehl. SVN braucht dringend diesen Befehl, wenn man bedenkt, wie häufig es zusätzliche Dateien auf der Festplatte Dump wird.
  2. Git hat den ‚bisect‘ Befehl. Es ist schön.
  3. SVN erstellt .svn Verzeichnisse in jedem einzelnen Ordner (Git schafft nur ein .git Verzeichnis). Jedes Skript , das Sie schreiben, und jedes grep Sie tun, müssen geschrieben werden , um diese .svn Verzeichnisse zu ignorieren. Sie müssen auch einen ganzen Befehl ( „svn export“) nur eine gesunde Kopie der Dateien zu erhalten.
  4. In SVN, jede Datei und Ordner kann aus einer anderen Revision oder Zweig kommen. Zunächst klingt es schön, diese Freiheit zu haben. Aber was das eigentlich bedeutet ist, dass es eine Million verschiedene Möglichkeiten für Ihre lokale Kasse vollständig nach oben geschraubt werden. (Zum Beispiel schlägt fehl, wenn „svn switch“ auf halbem Weg durch, oder wenn Sie einen Befehl falsch eingeben). Und das Schlimmste ist: Wenn Sie jemals in eine Situation kommen, wo einige Ihrer Dateien von einem Ort kommen, und einige von ihnen von einem anderen, der „svn status“ werden Ihnen sagen, dass alles normal ist. Sie müssen „svn info“ für jede Datei / Verzeichnis tun, um herauszufinden, wie seltsame Dinge sind. Wenn „git status“ sagt Ihnen, dass die Dinge normal sind, dann können Sie darauf vertrauen, dass die Dinge wirklich sind normal.
  5. Sie haben SVN zu sagen, wenn Sie etwas verschieben oder löschen. Git wird es nur herausfinden.
  6. Ignorieren Semantik sind leichter in Git. Wenn Sie ein Muster (zB * .pyc) ignorieren, wird es für ignoriert werden alle Unterverzeichnisse. (Aber wenn Sie wirklich etwas ignorieren wollen nur ein Verzeichnis, können Sie). Mit SVN, so scheint es , dass es keine einfache Möglichkeit ist , ein Muster in allen Unterverzeichnissen zu ignorieren.
  7. Ein weiterer Punkt Einbeziehung Dateien ignorieren. Git macht es möglich, „privat“ zu haben, ignorieren Einstellungen (mit der Datei .git / info / ausschließen), die sonst niemanden beeinflussen.
Beantwortet am 26/09/2008 um 01:18
quelle vom benutzer

stimmen
56

Warum Git besser als X beschreibt die verschiedenen Vor- und Nachteile von Git vs anderen SCMs“.

Kurz:

  • Git Tracks Inhalt anstatt Dateien
  • Zweige sind leicht und Zusammenführung ist einfach , und ich meine wirklich einfach .
  • Es verteilt, im Grunde jedes Repository ein Zweig ist. Es ist viel einfacher zu entwickeln , gleichzeitig und gemeinsam als mit Subversion, meiner Meinung nach . Es macht auch offline Entwicklung möglich.
  • Es keinen Workflow verhängen , wie auf gesehen der oben verlinkten Website gibt es viele Arbeitsabläufe möglich mit Git. Ein Subversion-Stil Workflow leicht nachgeahmt.
  • Git - Repositories sind viel kleiner in der Dateigröße als Subversion - Repositorys. Es gibt nur eine „.git“ Verzeichnis, im Gegensatz zu Dutzenden von „.svn“ Repositories (beachten Sie Subversion 1.7 und höher verwendet nun ein einzelnes Verzeichnis wie Git.)
  • Die Inszenierung Bereich ist genial, es erlaubt Ihnen , die Änderungen sehen Sie Teil Änderungen begehen, begehen und verschiedene andere Sachen zu tun.
  • Stashing ist von unschätzbarem Wert , wenn Sie „chaotisch“ Entwicklung zu tun, oder wollen einfach nur einen Fehler zu beheben , während Sie noch arbeiten auf etwas anderes (auf einem anderen Zweig).
  • Sie können die Geschichte neu schreiben , die zur Herstellung von Patch - Sets und Festsetzung Ihre Fehler groß ist ( 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 sich für viel länger, so ist dies natürlich wie es einige Schnittstellen in der Entwicklung sind. Einige gute umfassen TortoiseGit und GitHub for Mac .
  • Partielle Auscheckvorgänge / Klone von Endlagern im Moment nicht möglich sind (ich gelesen, dass es in der Entwicklung ist). Allerdings gibt es Submodul Unterstützung. Git 1.7+ unterstützt spärlich Kassen .
  • Es könnte schwieriger sein, zu lernen, auch wenn ich das nicht der Fall ist (vor etwa einem Jahr) angesehen habe. Git hat seine Schnittstelle kürzlich verbessert und ist sehr benutzerfreundlich.

In der am meisten vereinfach Nutzung, Subversion und Git sind so ziemlich das gleiche. Es gibt keinen großen 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 wirklich glänzt verzweigt und arbeiten mit anderen Menschen.

Beantwortet am 10/02/2009 um 05:18
quelle vom benutzer

stimmen
54

Google Tech Talk: Linus Torvalds auf git

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

Die Git Wiki des Vergleichsseite

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

Beantwortet am 03/08/2008 um 23:44
quelle vom benutzer

stimmen
26

Nun, es verteilt. Benchmarks zeigen, dass es wesentlich schneller (seiner verteilten Natur gegeben, Operationen wie diffs und Protokolle sind alle lokalen so natürlich schneller, es ist unglaublich in diesem Fall), und Arbeitsordner sind kleiner (was meiner Meinung nach immer noch bläst).

Wenn Sie auf Subversion arbeiten, oder einem anderen Client / Server - Versionskontrollsystem, erstellen Sie im Wesentlichen Kopien auf Ihrem Rechner arbeiten mit Check-out Revisionen. Dies stellt eine Momentaufnahme dessen , was das Repository aussieht. Sie aktualisieren Sie Ihre Arbeitskopie über Updates und Sie das Repository über Commits aktualisieren.

Mit einer verteilten Versionskontrolle, haben Sie nicht eine Momentaufnahme, sondern die gesamte Code-Basis. Möchten Sie ein Diff mit einem 3 Monate alten 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 von Ihrem zentralen Server getrennt sind, können Sie immer noch viele der Operationen, die Sie gewohnt sind. Mit anderen Worten: Sie haben nicht nur eine Momentaufnahme einer gegebenen Revision, sondern die gesamte Code-Basis.

Man könnte meinen, dass Git würde einen Haufen Platz auf Ihrer Festplatte aufnehmen, aber von ein paar Benchmarks die ich gesehen habe, dauert es eigentlich weniger. Fragen Sie mich nicht, wie. Ich meine, es wurde von Linus gebaut, weiß, dass er das eine oder andere über Dateisysteme, denke ich.

Beantwortet am 03/08/2008 um 23:47
quelle vom benutzer

stimmen
22

Die wichtigsten Punkte, die ich über DVCS wie solche:

  1. Sie können gebrochene Dinge begehen. Es spielt keine Rolle, weil andere Völker werden sie nicht sehen, bis Sie zu veröffentlichen. Der Veröffentlichungszeitpunkt ist unterschiedlich von Zeit zu begehen.
  2. Aus diesem Grund können Sie öfter begehen.
  3. Sie können kompletten functionnality fusionieren. Diese functionnality wird eine eigene Niederlassung hat. Alle Commits dieses Zweiges wird auf diese functionnality bezogen werden. Sie können es mit einem CVCS tun jedoch mit DVCS seine die Standardeinstellung.
  4. Sie können Ihre Geschichte (finden, wenn eine Funktion geändert) suchen
  5. Sie können einen Zug rückgängig machen, wenn jemand das Haupt-Repository vermasseln, müssen Sie nicht die Fehler zu beheben. Löschen Sie einfach die Zusammenführung.
  6. Wenn Sie eine Quellcodeverwaltung in einem beliebigen Verzeichnis müssen tun: git init. und Sie können verpflichten, Änderungen rückgängig gemacht, etc ...
  7. Es ist schnell (auch unter Windows)

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

Beantwortet am 04/09/2008 um 12:06
quelle vom benutzer

stimmen
15

Das Komische ist: Ich Host-Projekte in Subversion Repos, aber sie über das Git Clone Befehl zugreifen.

Bitte lesen Sie entwickeln mit Git auf einem Google Code Project

Obwohl nativ Google Code Subversion spricht, können Sie einfach Git während der Entwicklung verwenden. Die Suche nach „git svn“ schlägt vor, diese Praxis weit verbreitet ist, und auch wir empfehlen Ihnen, damit zu experimentieren.

Mit Git auf einer SVN-Repository gibt mir Vorteile:

  1. Ich kann arbeiten verteilt auf mehrere Maschinen, commiting und Ziehen von und zu ihnen
  2. Ich habe eine zentrale backup/public SVN - Repository für andere heraus zu überprüfen
  3. Und sie sind frei Git zu verwenden für ihre eigenen
Beantwortet am 02/10/2008 um 14:05
quelle vom benutzer

stimmen
11

Alle Antworten hier sind, wie erwartet, Programmierer centric, aber was passiert, wenn Ihre Firma Revision verwendet Kontrolle außerhalb des Quellcodes? Es gibt viele Dokumente, die nicht Quellcode sind, die aus der Versionskontrolle profitieren und sollte in der Nähe Code und nicht in einem anderen CMS leben. Die meisten Programmierer arbeiten nicht isoliert - wir arbeiten für Unternehmen als Teil eines Teams.

Mit dem im Verstand, zu vergleichen , Benutzerfreundlichkeit, sowohl in der Client - Werkzeugen und Ausbildung, zwischen Subversion und Git. Ich kann nicht ein Szenario sehen , wo jede verteilte Versionskontrollsystem leichter sein , wird zu einem Nicht-Programmierer zu verwenden oder zu erklären. Ich würde gerne als falsch bewiesen werden, denn dann würde ich in der Lage sein , git zu bewerten und habe tatsächlich eine Hoffnung , es von Menschen , die Version akzeptiert Kontrolle benötigen, die nicht Programmierer.

Selbst dann vom Management gefragt, ob, warum wir von einem zentralen zu verteilten Versionskontrollsystem bewegen sollten, ich hart bedrängt werden würde, um eine ehrliche Antwort zu geben, weil wir es nicht brauchen.

Disclaimer: Ich interessierte sich Subversion früh (um v0.29) so offensichtlich ich bin voreingenommen, aber die Unternehmen, die ich für seit dieser Zeit gearbeitet habe von meiner Begeisterung profitieren, weil ich dazu ermutigt haben, und unterstützt seine Verwendung. Ich vermute, das ist, wie es bei den meisten Software-Unternehmen geschieht. Mit so vielen Programmierern auf dem git fahrenden Zug springen, frage ich mich, wie viele Unternehmen gehen auf die Vorteile verzichten der Verwendung von Versionskontrolle außerhalb des Quellcodes? Auch wenn Sie separate Systeme für verschiedene Teams haben, sind Sie nicht auf einige der Vorteile aus, wie (einheitliche) Issue-Tracking-Integration, bei gleichzeitiger Erhöhung Wartung, Hardware und Ausbildungsanforderungen.

Beantwortet am 13/10/2009 um 08:01
quelle vom benutzer

stimmen
9

Subversion ist immer noch ein viel gebrauchtes Versionskontrollsystem, was bedeutet , dass es besser Werkzeugunterstützung hat. Sie werden für fast alle reifen SVN - Plugins finden IDE , und es gibt gute Explorer - Erweiterungen zur Verfügung (wie TurtoiseSVN). Other than that, ich werde mit einigen müssen Michael : Git ist nicht besser oder schlechter als Subversion, ist es anders.

Beantwortet am 18/09/2008 um 19:44
quelle vom benutzer

stimmen
8

David Richards WANdisco Blog auf Subversion / GIT

die ‚Gitterons‘ - - Die Entstehung von GIT hat mit ihm eine Art von DVCS Fundamentalisten gebracht, die nichts denken anders als GIT ist Mist. Die Gitterons scheinen Software-Engineering denken auf ihre eigene Insel passiert und oft vergessen, dass die meisten Unternehmen beschäftigen keine älteren Software-Ingenieure ausschließlich. Das ist in Ordnung, aber es ist nicht, wie der Rest des Markts denkt, und ich bin glücklich, es zu beweisen: GIT, am letzten Blick hatte weniger als drei Prozent des Markts, während Subversion in der Region von fünf Millionen Nutzer und etwa der Hälfte der Gesamtmarkt.

Das Problem, das wir sahen, war, dass die Gitterons feuern (billig) Schüsse auf Subversion. Subversion Tweets wie“ist so [slow / crappy / restriktiver / nicht gut riechen / schaut mich auf eine lustige Art] und jetzt habe ich GIT und [alles funktioniert in meinem Leben / meine Frau schwanger / Ich habe eine Freundin nach 30 Jahre versucht, / I gewann sechs mal auf dem Blackjack-Tisch läuft]. Du bekommst das Bild.

Beantwortet am 17/09/2010 um 19:22
quelle vom benutzer

stimmen
8

Eines der Dinge , über SubVersion , die mich ärgert ist , dass es einen eigenen Ordner legt nur in jedem Verzeichnis eines Projektes, während git eine im Stammverzeichnis legt. Es ist nicht , dass große Sache, aber kleine Dinge wie , dass addieren.

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

Beantwortet am 22/08/2008 um 16:24
quelle vom benutzer

stimmen
7

Git macht auch Branching und Merging 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 einen Zweig für jede neue Funktion mehr möglich zu schaffen. Oh und Git-Repositories sind sehr effizient mit Speicherplatz im Vergleich zu Subversion.

Beantwortet am 09/08/2008 um 04:22
quelle vom benutzer

stimmen
6

Einfach Git hat eine schöne Seite der tatsächlichen Nutzung des Vergleichens Git und SVN , die Ihnen eine Vorstellung davon geben wird, was die Dinge Git tun können (oder tun leichter) im Vergleich zu SVN. (Technisch gesehen basiert dieser auf einfache Git, die oben auf Git ein leichtes Wrapper ist.)

Beantwortet am 22/08/2008 um 16:19
quelle vom benutzer

stimmen
6

Es geht nur um die einfache Bedienung / Schritte erforderlich, um etwas zu tun.

Wenn ich ein einzelnes Projekt auf dem PC / Laptop bin Entwicklung, git ist besser, weil es viel einfacher einzurichten und zu bedienen ist. Sie brauchen nicht einen Server, und Sie brauchen nicht Repository-URLs bei der Eingabe zu halten, wenn Sie verschmilzt tun.

Wenn es nur 2 Personen wären, würde ich sagen, git ist auch einfacher, weil man nur schieben kann und von uns ziehen.

Wenn Sie darüber hinaus, dass, obwohl bekommen, würde ich für Subversion gehen, weil an diesem Punkt Sie einen ‚dedicated‘ Server oder Standort einrichten müssen.

Sie können dies genauso gut mit git wie mit SVN zu tun, aber die Vorteile von git erhalten durch die Notwendigkeit aufgewogen zusätzliche Schritte zu tun, mit einem zentralen Server zu synchronisieren. In SVN begehen Sie gerade. In git müssen Sie verpflichten git, dann Push-git. Der zusätzliche Schritt wird einfach ärgerlich, weil man so viel tut es am Ende.

SVN hat auch den Vorteil der besseren GUI-Tools, aber die git Ökosystem scheint schnell aufholen zu werden, so würde ich über diese auf lange Sicht keine Sorgen machen.

Beantwortet am 04/08/2008 um 00:38
quelle vom benutzer

stimmen
5

Ich mag Git, weil es tatsächlich Kommunikation Entwickler zu Entwickler auf einem mittleren bis großen Team hilft. Als verteiltes Versionskontrollsystem, durch seine Push / Pull-System, hilft es Entwicklern, ein Quellcode Öko-System zu schaffen, das über einen großen Pool von Entwicklern arbeiten an einem Projekt verwalten hilft.

Zum Beispiel sagen Sie 5 Entwicklern vertrauen und nur Codes von ihrem Repository ziehen. Jeder dieser Entwickler hat ihr eigenes Vertrauen Netzwerk von wo aus sie Codes ziehen. So wird die Entwicklung auf diesem Vertrauen Geweben des Entwicklers basiert, wo Code Verantwortung bei der Entwicklung der Gemeinschaft geteilt wird.

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

Beantwortet am 05/10/2008 um 17:52
quelle vom benutzer

stimmen
5

Git und DVCS im Allgemeinen ist für die Entwickler eine Menge Codierung unabhängig voneinander tun, weil jeder seine eigene Niederlassung hat. Wenn Sie eine Änderung von jemand anderem müssen, obwohl, hat sie zu ihrem lokalen Repo zu begehen und dann muss sie diese changeset Sie drücken oder Sie müssen es aus ihr ziehen.

Meine eigene Argumentation macht mich auch denken DVCS Dinge schwieriger für QA macht und Release-Management, wenn Sie Dinge wie zentralisiert Releases tun. Jemand hat dafür, dass die Push verantwortlich sein / ziehen von allen anderen Repository, Konflikte zu lösen, die vor dem begehen Zeit gelöst würden bei Anfangs wurden, dann den Build zu tun, und dann mit allen anderen Entwicklern erneut zu synchronisieren ihre repos.

All dies kann mit menschlichen Prozesse, natürlich angesprochen werden; DVCS brach nur etwas, das durch zentralisierte Versionskontrolle, um einige neue Annehmlichkeiten zu bieten wurde behoben.

Beantwortet am 04/08/2008 um 00:08
quelle vom benutzer

stimmen
4

Ich denke , Subversion ist in Ordnung .. bis Sie verschmelzen beginnen .. oder etwas kompliziert zu tun .. oder etwas zu tun , Subversion denkt kompliziert ist (wie Abfragen zu tun , um herauszufinden , welche mit einer bestimmten Datei messed Zweig, wo eine Änderung tatsächlich kommt, Erfassen Copy & Pasten , etc)...

Ich bin nicht einverstanden mit der gewinnenden Antwort, die sagte : Hauptvorteil von GIT ist offline arbeiten - es ist sicherlich sinnvoll, aber es ist eher wie ein extra für meinen Anwendungsfall. SVK kann offline arbeiten, noch ist es keine Frage für mich , die man meine Lernzeit in) zu investieren.

Es ist nur so, dass es unglaublich kraftvoll und schnell und gut -nach die Konzepte Gewöhnung - sehr nützlich (ja, in diesem Sinne: benutzerfreundlich).

Weitere Einzelheiten zu einer Verschmelzung Geschichte sehen: Mit git-svn (oder ähnlich) * nur * zu helfen , mit einem svn merge?

Beantwortet am 27/07/2010 um 16:40
quelle vom benutzer

stimmen
4

Einige Antworten haben auf diese hingewiesen, aber ich möchte 2 Punkte explizit machen:

1) Die Fähigkeit , selektiv Commits zu tun (zum Beispiel git add --patch). Wenn Ihr Arbeitsverzeichnis mehrere Änderungen enthält , die nicht Teil der gleichen logischen Änderung sind, macht Git es sehr einfach , eine zu machen verpflichten , dass nur ein Teil der Änderungen umfasst. Mit Subversion, ist es schwierig.

2) Die Fähigkeit, ohne die Änderung der Öffentlichkeit zu begehen. In Subversion jede begehen ist sofort öffentlich und damit unwiderruflich. Dies begrenzt stark die Fähigkeit des Entwicklers zu „begehen früh, zu begehen oft“.

Git ist mehr als nur ein VCS; es ist auch ein Werkzeug-Patches für die Entwicklung. Subversion ist nur ein VCS.

Beantwortet am 07/08/2009 um 15:59
quelle vom benutzer

stimmen
3

Das ist die falsche Frage werden. Es ist nur allzu leicht auf git der Warzen zu konzentrieren und ein Argument zu formulieren, warum besser Subversion ist angeblich, zumindest für einige Anwendungsfälle. Die Tatsache, dass git ursprünglich als Low-Level-Versionskontrolle Bausatzes entworfen und hat einen barocken Linux-Entwickler-orientierte Schnittstelle macht es einfacher für die heiligen Kriege Traktion und wahrgenommen zu legitimieren. Git Befürworter der Trommel mit Millionen von Workflow-Vorteile schlagen, die svn Jungs unnötig verkünden. Ziemlich bald die ganze Debatte wird als zentrale eingerahmt vs verteilt, die die Interessen des Unternehmens SVN-Tool Community dient. Diese Unternehmen, die in der Regel die überzeugendsten Artikel über Subversion Überlegenheit im Unternehmen löschte,

Aber hier ist das Problem: Subversion ist ein architektonisches Sackgasse .

Während Sie git nehmen und eine zentrale Subversion Ersatz ganz einfach zu bauen, trotz um sein für mehr als doppelt so lang SVN hat nie in der Lage zu bekommen, selbst grundlegende merge-Tracking überall arbeiten in der Nähe sowie in git tut. Ein wesentlicher Grund dafür ist die Design-Entscheidung zu treffen Zweige des gleichen wie Verzeichnisse. Ich weiß nicht, warum sie auf diese Weise ursprünglich ging, macht es sicherlich teilweise Auscheckvorgänge sehr einfach. Leider macht es auch unmöglich Geschichte richtig zu verfolgen. Jetzt offensichtlich sollen Sie Subversion-Repository Layout Konventionen Zweige trennen von regelmäßigen Verzeichnisse und svn verwendet einige Heuristiken, um die Dinge für den täglichen Gebrauch Fällen zu arbeiten. Aber all dies ist tapeziert nur eine sehr schlechte über und die Begrenzung der Low-Level-Design-Entscheidung. Die Möglichkeit, einen einen Repository-weise diff (anstattes Verzeichnis wiese diff) ist einfach und kritische Funktionalität für ein Versionskontrollsystem und vereinfacht die Einbauten, ist es möglich zu bauen intelligente und nützliche Features auf ihn zu machen. Sie können in dem Aufwand sehen, die in Verlängerung Subversion gesetzt wurden, und doch, wie weit dahinter aus der aktuellen Ernte von modernem VCSes in Bezug auf den grundlegenden Operationen wie merge Auflösung.

Hier ist mein Herz-Filz und Agnostiker Beratung für alle, die immer noch glaubt, Subversion ist gut genug für die absehbare Zukunft:

Subversion wird nie zu den neueren Rassen von VCSes aufholen, die aus den Fehlern von RCS und CVS gelernt haben; es ist eine technische Unmöglichkeit, wenn sie das Repository-Modell von Grund auf umrüsten, aber dann wäre es nicht wirklich svn würde es? Unabhängig davon, wie viel man nicht die Möglichkeiten eines modernen VCS, Ihre Unwissenheit wird Sie nicht von den Tücken des Subversion schützen, von denen viele Situationen, die unmöglich sind oder leicht in anderen Systemen aufgelöst.

Es ist äußerst selten, dass die technische Unterlegenheit einer Lösung so eindeutig ist, wie es mit SVN ist, sicherlich würde ich nie eine solche Meinung über Win-vs-Linux oder Emacs-vs-vi angeben, aber in diesem Fall ist es so, Steuer clearcut und Quelle ist so ein grundlegendes Instrument im Arsenal der Entwickler, dass ich es fühle eindeutig angegeben werden muss. Unabhängig von der Anforderung svn aus organisatorischen Gründen zu verwenden, ich flehe alle SVN-Benutzer nicht ihren logischer Verstand konstruiert einen falschen Glauben zu lassen, dass modernere VCSes ist nur nützlich für große Open-Source-Projekte. Unabhängig von der Art Ihrer Entwicklungsarbeit, wenn Sie ein Programmierer sind, werden Sie ein effektiverer Programmierer sein, wenn Sie lernen, wie man verwendet besser gestaltetes VCSes, ob es Git, Mercurial, Darcs, oder viele andere.

Beantwortet am 29/05/2011 um 18:30
quelle vom benutzer

stimmen
3

Ich liebe absolut in der Lage in Git Ortsvereine meine Quellcode zu verwalten sein, ohne das Wasser des zentralen Repository muddying auf. In vielen Fällen werde ich Code aus dem Subversion-Server Kasse und eine lokale Git-Repository laufe nur in der Lage sein, dies zu tun. Es ist auch toll, dass ein Git-Repository initialisiert nicht das Dateisystem mit einem Bündel von lästigen .svn Ordnern überall nicht verschmutzen.

Und so weit wie Windows-Tool-Unterstützung, Griffe TortoiseGit die Grundlagen sehr gut, aber ich immer noch lieber die Befehlszeile, wenn ich das Protokoll anzeigen möchten. Ich mag die Art und Weise Schildkröte {Git | SVN} hilft, bei der logs Lesen begehen.

Beantwortet am 10/02/2010 um 23:54
quelle vom benutzer

stimmen
3

Dank der Tatsache, jeder Befehl läuft so ziemlich in es muss nicht ständig mit einem zentralen Server kommuniziert weniger als eine Sekunde (offensichtlich git Push / Pull / holt langsamer ist, nur weil sie SSH-Verbindungen initalise haben). Branching weit weit einfacher ist (ein einfacher Befehl zum Zweig, ein einfacher Befehl zu fusionieren)

Beantwortet am 30/08/2008 um 13:01
quelle vom benutzer

stimmen
2

Für Menschen , für eine gute Git GUI suchen, Syntevo SmartGit könnte eine gute Lösung sein. Seine proprietären, aber kostenlos für nicht-kommerzielle Nutzung, läuft unter Windows / Mac / Linux und sogar unterstützt SVN eine Art von git-svn Brücke verwenden, glaube ich.

Beantwortet am 09/03/2011 um 15:05
quelle vom benutzer

stimmen
2

Eric Sink aus SourceGear schrieb Reihe von Artikeln über Unterschiede zwischen verteilten und nicht verteilten Version Kontrollsystemen. Er vergleicht Vor- und Nachteile der beliebtesten Versionskontrollsysteme. Sehr interessant zu lesen.
Artikel finden Sie auf seinem Blog zu finden, www.ericsink.com :

Beantwortet am 13/10/2009 um 14:36
quelle vom benutzer

stimmen
2

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

Mit Git erhalten Sie eine flexiblere VCS. Sie können es auf die gleiche Weise wie SVN mit einer Remote-Repository verwenden, in dem Sie alle Änderungen. Aber man kann es auch meist offline verwenden und nur drücken Sie die Änderungen von Zeit zu Zeit auf die Remote-Repository. Aber Git ist komplexer und hat eine steilere Lernkurve. Ich fand mich in der ersten Zeit zu falschen Zweige zu begehen, wodurch Zweige indirekt oder Fehlermeldungen mit nicht viel Informationen über den Fehler bekommen und wo muss ich mit Google-Suche besser Informationen zu erhalten. Einige einfache Dinge wie Substitution von Markern ($ Id $) funktioniert nicht aber GIT hat eine sehr flexible Filter und Hakenmechanismus, um eigene Skripte zu fusionieren und so erhalten Sie alle Dinge, die Sie brauchen, und mehr, aber es braucht mehr Zeit und das Lesen der Dokumentation ;)

Wenn Sie mit Ihrem lokalen Repository meist offline arbeiten müssen Sie keinen Backup, wenn etwas auf dem lokalen Computer verloren geht. Mit SVN sind Sie meist mit einer Remote-Repository arbeiten, die auf einem anderen Server auch gleichzeitig Ihr Backup ist ... Git kann in der gleichen Art und Weise arbeiten, aber das war nicht das Hauptziel von Linus zu so etwas wie SVN2 hat. Es war für die Linux-Kernel-Entwickler und die Bedürfnisse eines verteilten Versionskontrollsystem entwickelt.

Ist Git besser als SVN? Entwickler, die nur eine Version der Geschichte und einen Backup-Mechanismus brauchen ein gutes und einfaches Leben mit SVN. Entwickler arbeiten oft mit Zweigen, Prüfung mehr Versionen zur gleichen Zeit oder meistens offline arbeiten, kann aus den Merkmalen der Git profitieren. Es gibt einige sehr nützliche Funktionen wie stashing mit SVN nicht gefunden, die das Leben leichter machen können. Aber auf der anderen Seite nicht alle Menschen werden alle Funktionen benötigen. So kann ich nicht die Toten von SVN sehen.

Git braucht etwas bessere Dokumentation und die Fehlerberichterstattung muss mehr hilfreich. Auch die bestehenden nützlich GUIs sind nur selten. Dieses Mal habe ich fand nur 1 GUI für Linux mit Unterstützung der meisten Git - Features (git-Cola). Eclipse - Integration funktioniert , aber es ist nicht offiziell freigegeben , und es gibt keine offizielle Update - Site (nur einig externe Update - Site mit periodischem baut aus dem Stamm http://www.jgit.org/updates ) So der am meisten bevorzugten Art und Weise Git zu verwenden , um diese Tage ist die Befehlszeile.

Beantwortet am 13/10/2009 um 14:14
quelle vom benutzer

stimmen
1

Warum ich denke, Subversion ist besser als Git (zumindest für die Projekte auf ich arbeite), vor allem wegen seiner Benutzerfreundlichkeit und einfacher Workflow:

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

Beantwortet am 22/10/2010 um 17:25
quelle vom benutzer

stimmen
1

Ich habe in letzter Zeit in Git Land wurde Behausung, und Ich mag es für persönliche Projekte, aber ich würde noch von Subversion angesichts der Veränderung im Denken der erforderlichen von Personal nicht in der Lage sein, Arbeitsprojekte zu schalten, ohne ohne Pressen Vorteile. Darüber hinaus ist das größte Projekt , das wir im Hause laufen ist extrem abhängig von svn: externals , die von dem, was ich bisher gesehen habe, nicht so schön und nahtlos in Git funktionieren.

Beantwortet am 25/04/2010 um 22:35
quelle vom benutzer

stimmen
1

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

Ich denke, es ist ziemlich sicher ist, dass unter den Entwicklern zu sagen, die SVN Vs. Git Argument ist nun seit einiger Zeit tobt, mit allen auf dem ihre eigene Meinung haben ist besser. Dies wurde auch in dem von den Fragen, die während unserer Webinar auf Subversion in 2010 und darüber hinaus gebracht.

Hyrum Wright, unser Direktor von Open Source und dem Präsident für die Subversion Corporation, spricht über die Unterschiede zwischen Subversion und Git, zusammen mit anderem Distributed Version Control System (DVCS).

Er spricht auch über die anstehenden Veränderungen in Subversion, wie Arbeitskopie Next Generation (WC-NG), die er eine Reihe von Git Benutzern verursachen glaubt zu Subversion konvertieren zurück.

Haben Sie eine Uhr seines Videos und lassen Sie uns wissen, was Sie denken, entweder in diesem Blog zu kommentieren, oder in unserem Forum posten. Die Registrierung ist einfach und dauert nur einen Moment nehmen!

Beantwortet am 10/02/2010 um 19:51
quelle vom benutzer

stimmen
1

Git in Windows ist recht gut jetzt unterstützt.

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

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

Beantwortet am 10/02/2010 um 17:29
quelle vom benutzer

stimmen
1

Erstens scheint die gleichzeitige Versionskontrolle wie ein einfaches Problem zu lösen. Es ist gar nicht. Sowieso...

SVN ist durchaus nicht intuitiv. Git ist noch schlimmer. [Sarkastisch-Spekulation] Dies könnte, weil die Entwickler, dass wie harte Probleme wie gleichzeitige Versionskontrolle, nicht viel Interesse haben eine gute UI zu machen. [/ Sarkastisch-Spekulation]

SVN Fans denken , dass sie nicht ein verteiltes Versionskontrollsystem benötigen. Ich dachte , das auch. Aber jetzt, wo wir Git verwenden ausschließlich, bin ich ein Gläubiger. Jetzt arbeitet die Versionskontrolle für mich und das Team / Projekt statt nur für das Projekt arbeiten. Wenn ich einen Zweig benötigen, verzweigen ich. Manchmal ist es ein Zweig, der einen entsprechenden Zweig auf dem Server hat, und manchmal ist es nicht. Ganz zu schweigen von all den anderen Vorteilen , die ich habe studieren werde weitergehen ( zum Teil dank der arkanen und absurd Mangel an Benutzeroberfläche , die ein modernes System zur Versionskontrolle ist).

Beantwortet am 03/01/2010 um 13:45
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more