Git zentralisiert vs dezentralisiert

Hallo,

Git wird ja jetzt ueberall verwendet. Aber Git ist ja dezentralisiert.
Jetzt war ich kuerzlich in einer Firma und sie meinten sie wuerden immer noch subversion verwenden. Ihre Begruendung subversion ist zentralisiert. Da dachte ich mir hm eigentlich haben die ja recht. Zentralisiert reicht doch...

scrontch

Im allgemeine wird man in einem Unternhemen immer eine zentralisierte Organisation nehmen.
Denn irgendwo muss ja die Referenz-Instanz stehen, die vom Build- und Test-system genommen und bei Bedarf zum Kunden geliefert wird.
Aber wer dezentralisiert kann kann eben auch zentralisiert. Und das Plus an Flexibilität kostet praktisch nichts.
Zumal es durchaus auch im Unternhemen Szenarios für dezentrales Entwickeln gibt, z.b. wenn zwei Entwickler was untereinander testen wollen ohne dafür jetzt gleich ne Branch für alle sichtbar machen zu wollen.

Finnegan

Auch mit Git kann ich mir einen Server mit einem Repository hinstellen und sagen: "Das ist jetzt die autoritative Instanz aus der die offiziellen Releases gebaut werden".
Schau dir die ganzen größeren Projekte an, die Git verwenden, da gibt es überall ein offizielles Repository (oder auch sämtliche Projekte auf GitHub).

Zentralisierung ist ein Null-Argument für oder gegen Git/Subversion. Maßgebend sind die anderen technischen Argumente, u.a. auch die Dezentralisierung:
Mit Git ist es wesentlich leichter eine Weile auf einem lokalen, experimentellen Branch zu entwickeln und dabei regelmäßig Commits durchzuführen (also
sauber über jede Änderung Buch zu führen) ohne dass der experimentelle Code ins "offizielle" Repo eingecheckt werden muss. Das geschieht erst wenn
die neue Entwicklung abgeschlossen ist und man einen Merge mit dem offizellen "Master" macht.

Ich behaupte dass bei Git durch die Dezentralisierung die Hemmschwelle, einen neuen Branch aufzumachen geringer ist, was letztendlich den Vorteil hat,
dass mehr Code-Änderungen durch Commits dokumentiert werden. Wie sieht es denn in der besagten Firma aus, wenn ein Mitarbeiter an einem neuen
Feature arbeitet? Machen die mehrere Commits am Tag für jeden Arbeitsschritt (bei Git durchaus üblich) oder wutschteln die erstmal ein paar Tage rum
und checken dann das komplette Feature ein?

Printe

DerHammer schrieb:

Aber Git ist ja dezentralisiert.

Nein. Git kann beides, man kann es so oder so verwenden.

sie meinten sie wuerden immer noch subversion verwenden. Ihre Begruendung subversion ist zentralisiert.

Das stimmt, und solange das zur Arbeitsweise passt (zentral verwaltetes Repo, keine mobile Entwicklung ohne Verbindung zum Repo), spricht nichts dagegen, Subversion zu behalten. Ein Wechsel der Infrastruktur bedeutet immer Aufwand:

Jemand muss sich tief in Git einarbeiten, so tief, dass er ein Repo administrieren und das alte Subversion-Repo zu Git migrieren kann.
Das ganze Team muss sich weit genug in Git einarbeiten, um sicher damit umgehen zu können.
Es müssen Regeln aufgestellt, vermittelt und allgemein akzeptiert werden, wie mit zentralen und verteilten Repos umzugehen ist.
Arbeitsumgebungen (IDEs, automatische Build- und Testsysteme, ...) müssen umgestellt und getestet werden.
Evtl. muss neue Server-Hardware angeschafft werden, was auch wieder Aufwand (Installation, Pflege, Updates, Backups) bedeutet.

Das ist nicht wenig, und solange niemandem ernsthaft was an Subversion fehlt, ist es keine dumme Idee, dabei zu bleiben.

Printe

Finnegan schrieb:

Mit Git ist es wesentlich leichter eine Weile auf einem lokalen, experimentellen Branch zu entwickeln und dabei regelmäßig Commits durchzuführen (also sauber über jede Änderung Buch zu führen) ohne dass der experimentelle Code ins "offizielle" Repo eingecheckt werden muss.

Auch mit Subversion ist es überhaupt kein Thema, Branches anzulegen, darauf zu entwickeln und kleinteilig zu committen. Ich arbeite mit Subversion und committe normalerweise mehrmals am Tag, immer wenn ein Schritt erledigt ist und bevor ich den nächsten anfange.

Das geschieht erst wenn die neue Entwicklung abgeschlossen ist und man einen Merge mit dem offizellen "Master" macht.

Selbiges gilt für Subversion.

Ich behaupte dass bei Git durch die Dezentralisierung die Hemmschwelle, einen neuen Branch aufzumachen geringer ist

Und ich behaupte, dass dadurch auch das Risiko steigt, irgendwann vor lauter Branches den Wald nicht mehr zu sehen: Verdammt, auf welcher meiner 30 Verzweigungen hatte ich XYZ nochmal gemacht? Eine Entwicklung wird nicht um so besser, je mehr Branches sie hat, ähnlich wie ein Objektmodell nicht um so besser ist, je tiefer die Ableitungshierarchie ist. Man sollte sich beim Programmieren nicht von irgendwelchen Hemmschwellen leiten lassen, sondern von vernünftigen Entscheidungen. Und das ist unabhängig von Git oder Subversion.

Wie sieht es denn in der besagten Firma aus, ... oder wurschteln die erstmal ein paar Tage rum und checken dann das komplette Feature ein?

Wie gesagt - man kann jedes Werkzeug richtig und falsch benutzen. Das ist nicht die Schuld des Werkzeugs.

Printe schrieb:

Das stimmt, und solange das zur Arbeitsweise passt (zentral verwaltetes Repo, keine mobile Entwicklung ohne Verbindung zum Repo), spricht nichts dagegen, Subversion zu behalten.

Mit git hat jeder sein eigenes Repo, worauf er entwickeln und commiten kann. Auch mit Zwischenstufen die noch nicht richtig funktionieren, aber dennoch eine Dokumentation erhalten.
Wenn dann ein sauberer Zustand erreicht wurde, kann man zum master git commiten.

Das ist schon ein Vorteil. Bei Subversion müsste man mit branches arbeiten -> unflexibel.

Printe

computertrolls schrieb:

Bei Subversion müsste man mit branches arbeiten -> unflexibel.

Natürlich würde man bei Subversion mit Branches arbeiten, genau dafür sind die da. Und warum das unflexibel sein soll, das müsstest du erst noch erklären.

dot

Ich sag nur: Mercurial

Tobiking2

Printe schrieb:

computertrolls schrieb:

Bei Subversion müsste man mit branches arbeiten -> unflexibel.

Natürlich würde man bei Subversion mit Branches arbeiten, genau dafür sind die da. Und warum das unflexibel sein soll, das müsstest du erst noch erklären.

Ich würde nicht sagen, dass Branches unflexibel sind, aber mir gefällt nicht wie sie in SVN implementiert sind. Es sind praktisch nur Ordner, die mit den mergeinfo properties eine Beziehung zu anderen Ordner haben.

Deswegen gibt es keinen SVN Befehl um zu einem Branch zu wechseln oder zu mergen. Das geht alles über URLs. Ich hab mir deswegen einen Wrapper erstellt der die URL aus dem Branchnamen generiert. Das funktioniert aber nur solange die Branches die gleiche Struktur wie der trunk haben. Da man im SVN auch einzelne Order (wir haben mehrere Projekte pro Repo) aus dem trunk branchen und mergen kann, sparen sich viele Entwickler die kompletten Branches. So lässt sich die URL nicht mehr einfach nur aus dem Branchnamen herleiten. Da bleibt nichts anderes als sich die URL zu browsen, was sich über den Server eher langsam anfühlt.

Die mergeinfo properties sind auch wie Code anfällig für Mergekonflikte. Wir haben da ein paar Branches rumliegen, bei denen keiner mehr weiß welchen Stand die haben, weil die mergeinfos nicht mehr stimmen. Die müsste man manuell aus der History rekonstruieren. Die Konflikte vermeiden geht leider nicht zuverlässig, wenn man mehrere Versionen pflegen muss und deswegen zwischen Branches von Branches merged.

SideWinder

Schonmal Branch-Creation-Time und Branch-Switch-Time zwischen Subversion und Git verglichen? Branches in Subversion sind imho sehr schwerfällig und nicht für kleine Änderungen sondern nur größere Stories gedacht.

MfG SideWinder

Dank git-svn ist es mir fast egal ob svn- oder git-server.

Aber bei den SVN-Workflows, die ich kennengelernt habe, wurden immer mehrere Bugs in einem SVN-Commit gesammelt. mit schlechten Diffs.

Ist das bei euch anders? Ein SVN-Commit pro Bugfix? Mit SVN-Client ohne lokale commits macht das ja keinen Spaß.

Printe

man git reset schrieb:

Ist das bei euch anders? Ein SVN-Commit pro Bugfix?

Ja. Hab ich doch geschrieben, immer wenn ich einen Schritt fertig habe (einen Bugfix, ein Feature), wird der committet.

Das war nicht immer so, und ich gebe zu, dass meine Erfahrungen mit git einen gewissen Einfluss darauf hatten. Aber es erweist sich immer wieder als praktisch.

Mit SVN-Client ohne lokale commits macht das ja keinen Spaß.

Mit "lokale commits" meinst du einen SVN-Server im LAN? Den haben wir natürlich, oder denkst du, wir speichern unser Software-Knowhow in einer Cloud, außerhalb unserer Kontrolle?

Nein, ich meine das git-Repo lokal am eigenen Arbeitsplatz. Ohne dem, wenn du immer direkt jede Änderung zum Server pushst, hast du doch bestimmt eine hohe "fixup-Commit"-Quote und die einzelnen Commits haben selten noch den ganzen Stand.

Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?

Printe

man git reset schrieb:

Ohne dem, wenn du immer direkt jede Änderung zum Server pushst, hast du doch bestimmt eine hohe "fixup-Commit"-Quote und die einzelnen Commits haben selten noch den ganzen Stand.

? Verstehe ich nicht. Was meinst du mit "fixup-commit" und "selten den ganzen Stand"?

Wenn ich was fertig habe, mache ich svn commit -m "kommentar". Vorher prüfe ich mit svn status und svn diff, ob alles Nötige drin ist im Commit (und alles Unnötige draußen).

Machst du das etwa nicht? Committest du mit der heißen Nadel? Brauchst du mehrere Anläufe, bis du endlich alles im Kasten hast? Dann ist nicht git die Lösung, sondern mehr Sorgfalt beim Arbeiten.

Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?

Dass ein Kollege hier reinstürzt und SOFORT dies und das von mir haben will und auf KEINEN Fall warten kann, das passiert nicht. Der muss mir sagen "ich brauch das in ein paar Tagen", dann mache ich das rechtzeitig. Umgekehrt natürlich genauso, auch ich muss früh genug Bescheid sagen, wenn andere was für mich tun sollen.

Und wenn doch was hart dazwischenfliegt, dann kann das nur ein Hotfix sein, der auf einer bereits releasten Version gemacht werden muss. Das heißt, ich muss mir dafür eh den zugehörigen Release-Branch holen, und der ist natürlich sauber.

Was willst du hier eigentlich beweisen? Dass Subversion kacke ist, dass jeder, der noch damit arbeitet, wohl hinterm Mond lebt? Ich weiß sehr wohl, dass git Vorzüge hat, und würden wir heute nochmal ein VCS einführen, dann würde wir uns wohl für git entscheiden. Aber die Entscheidung ist vor mehr als 10 Jahren gefallen, und wir verwalten sehr viel mit Subversion, bei weitem nicht nur Software-Quellcode. Das alles umzustellen und zu migrieren würde Monate verschlingen, und dafür tut Subversion einfach noch nicht genug weh.

Printe schrieb:

Das alles umzustellen und zu migrieren würde Monate verschlingen, und dafür tut Subversion einfach noch nicht genug weh.

Das kann ich mir nicht vorstellen.

Ich würde sogar vermuten, dass es Tools gibt, mit dem man den Umstieg automatisieren kann, sogar inklusive der Versionshistorie.

Open Source Projekte kriegen es ja auch hin und die haben viel weniger Zeit.

Tobiking2

man git reset schrieb:

Und was machst du, wenn du gerade mitten in einer Aufgabe steckst und dann kommt etwas ganz anderes dazwischen. Wie erledigst du dann die neue Aufgabe mit einer sauberen Codebasis?

Per svn diff einen Patch erzeugen, Änderungen reverten und hinterher Patch wieder einstellen.

computertrolls schrieb:

Ich würde sogar vermuten, dass es Tools gibt, mit dem man den Umstieg automatisieren kann, sogar inklusive der Versionshistorie.

Das Repo selber ist nicht das Problem. Aber danach muss man sämtliche Build-Jobs und andere Skripte, die auf SVN basieren, umstellen.

Printe schrieb:

Was willst du hier eigentlich beweisen?

Gar nichts
Ich habe darauf hingewiesen, dass man git auch als SVN-Client benutzen kann.

Dann muss in der Firma nichts umgestellt werden und man hat trotzdem viele Vorteile von git (eben das Patch-Management was Tobiking2 manuell macht und Du scheinbar nicht nötig hast).

Sarkast

Printe schrieb:

Ein Wechsel der Infrastruktur bedeutet immer Aufwand:

Jemand muss sich tief in Git einarbeiten, so tief, dass er ein Repo administrieren und das alte Subversion-Repo zu Git migrieren kann.

Das ganze Team muss sich weit genug in Git einarbeiten, um sicher damit umgehen zu können.

Es müssen Regeln aufgestellt, vermittelt und allgemein akzeptiert werden, wie mit zentralen und verteilten Repos umzugehen ist.

Arbeitsumgebungen (IDEs, automatische Build- und Testsysteme, ...) müssen umgestellt und getestet werden.

Evtl. muss neue Server-Hardware angeschafft werden, was auch wieder Aufwand (Installation, Pflege, Updates, Backups) bedeutet.

Das ist nicht wenig, und solange niemandem ernsthaft was an Subversion fehlt, ist es keine dumme Idee, dabei zu bleiben.

Es ist eine der dümmsten Ideen aller Zeiten. Ich kann parallell Git und SVN auf eine Kiste als Zentralinstanz packen und den Übergang administrativ leiten. Selten so was smoothes erlebt. Mit Tortoise Tools gehts ganz locker, meinetwegen mit Doppeleinpflege.
Aber mach mal nen Server temporär tot, da geht mit SVN nix weida. Bei Git können alle weiterwursteln, bis zentral wieder was geht. Unschätzbare Vorteile. Jeder kann weiter forken und seinen Testkram weiter sichern, bis er seinen Teil weitergibt. Kann SVN ohne Zentralinstanz einfach nicht.