git vs Subversion - Vor- und Nachteile [geschlossen]

Ich bin seit vielen Jahren ein Benutzer von SVN und ich kann nicht sagen, dass ich total glücklich darüber bin. Vor ein paar Tagen hat mich mein Partner gebeten, einen Blick auf git zu werfen und zu sagen, dass "es eine bessere Leistung hat, das Zusammenführen und Verzweigen einfacher macht".

Ich habe einige Vergleichsartikel zwischen Git und SVN gelesen und würde mich freuen, wenn die Leute die Vor- und Nachteile beider Versionskontrollsysteme zusammenfassen könnten.

Jetzt untersuche ich Menschen, die von einem System zu einem anderen gewechselt sind und subjektive Meinungen hören.

Ich weiß für mich selbst, dass mir die Funktionsweise von SVN sehr gut gefällt. Ich habe ein zentrales Repository, in dem Benutzer auschecken können, und weiß, dass ich daraus eine Live-Entwicklungskopie und eine Live-Produktionskopie bereitstellen kann. Manchmal haben wir jedoch Probleme beim Sortieren von Konflikten oder anderen Fehlern Jedes Mal, wenn wir den Verlauf einer Datei unterscheiden oder untersuchen müssen, müssen wir uns mit der Netzwerklatenz befassen.

Auf der anderen Seite klingt eine verteilte Plattform auch nach Kopfschmerzen. Wie können Sie die Zugriffe steuern? Haben Sie ein zentrales Repository, von dem aus Sie pushen und aktualisieren?

Vielen Dank, dass Sie mehr Licht in das Thema gebracht haben.

Versuchen Sie, die beiden Tools aus der Sicht eines Systemadministrators oder als Programmierer zu vergleichen? Wenn Sie dies aus Sicht eines Programmierers betrachten, sollten Sie dies möglicherweise beim Stapelüberlauf erfragen. Oder noch besser, vielleicht sollten Sie sich ansehen, was bereits nach " git svn " gefragt wurde .

• /programming/871/why-is-git-better-than-subversion
• /programming/161541/svn-vs-git
• /programming/536779/git-or-svn-for-rails-app
• /programming/1239577/git-and-svn-on-windows
• /programming/1310572/what-are-pros-and-cons-of-using-git-svn

Die Sache mit git und svn ist, dass es kein Entweder-Oder-Vorschlag ist. Sie können ein SVN-Repository ausführen und Ihre Entwickler können mit git-svn interagieren, wenn sie glauben, dass git in einem bestimmten Fall ein besseres Tool ist.

Es gibt wirklich keine Profis für Subversion über Git. Während Git verteilt wird, kann jeder mithilfe von Remote-Tracking-Zweigen von einem zentralen Repository aus arbeiten. Git ist schneller, flexibler und das Zusammenführen funktioniert tatsächlich. Außerdem können Sie realistisch offline arbeiten, während Sie mit Subversion keine Änderungen festschreiben können, wenn Sie keine haben. Sie können einfacher mit einzelnen Festschreibungen in git arbeiten, als wenn eine einzelne Festschreibungs-ID den Status des Repositorys in svn darstellt.

Der Zugriff wird entweder durch Benutzer- / Gruppenkonten auf dem Git-Server gesteuert (Sie müssen das Ursprungs-Repository mit 'git init --bare --shared' initialisieren, damit die Berechtigungen entsprechend festgelegt werden) oder mithilfe von ssh-Schlüsseln. Eine sehr detaillierte Zugriffskontrolle kann mithilfe von 'gitosis' eingerichtet werden, einem Addon eines Drittanbieters.

Es dauert eine Weile, bis man sich an die Arbeit mit Git gewöhnt hat, wenn man an SVN gewöhnt ist (wir haben das gerade in meinem Büro durchgearbeitet), aber Git ist viel leistungsfähiger.

Wenn Sie eine großartige Anleitung benötigen, besuchen Sie http://progit.org - es ist eine vollständige Online-Kopie eines Open-Source-Buches.

In meinem Team sind wir gerade dabei, unsere Kontrollversionssysteme von svn auf git umzustellen. Git hat eine etwas härtere Lernkurve, daher begann ich mich damit vertraut zu machen und brachte den Entwicklern dann bei, wie man es benutzt. Sie müssen alle Vorteile eines Versionskontrollversionssystems kennen: mehrere Zweige, kein zentrales Repository, Geschwindigkeit usw.

Wie Sie hatten wir ein System zum Bereitstellen unserer Websites, sodass wir so etwas wie einen zentralen Git-Server behalten, auf dem die Änderungen von und zu den Computern der Entwickler gezogen und übertragen werden. Unsere Websites beziehen die Änderungen von diesem "zentralen Server", und der Rest des Bereitstellungsprozesses ähnelt dem mit svn.

Wir haben versucht, SVN- und Git-Repositorys nicht zu mischen. Wir haben damit begonnen, unsere kleineren Websites zu migrieren und neue Git-Repositorys für Hauptwebsites zu erstellen, als wären sie eine neue Version. Der Zugriff wird mit SSH-Schlüsseln verwaltet. Außerdem verwenden wir gitweb als Webschnittstelle (unser SVN-System basiert auf http).

Es funktioniert, es ist keine Änderung von einem Tag zum anderen, und wir versuchen, dass Entwickler diese Änderung nicht als Ärger ansehen, sondern als neue Fähigkeit, ein Tool zu erlernen, das am Ende unser eigenes System verbessert.