SVN vs GIT

[mfernau]

Hallo Leute,

ich muss/möchte mich mit dem Thema Versionsverwaltung beschäftigen.

Kurz zu meiner Situation:
In meiner Firma arbeiten derzeit (inkl mir) 3 Entwickler. Ein 4. kommt demnächst hinzu. VCS ist leider (oder zum Glück?) bei allen meiner Mitarbeiter ein Fremdwort. Außer mir arbeitet niemand mit solch einem System.
Grund: Ich habe die Firma von meinem Vater entwicklungsseitig übernommen und in der Historie der Firma wurde ein solches System nie verwendet. Da ich komplett eigenständige Tools und Software schreibe die direkt nichts mit unserer "Hauptsoftware" zu tun haben, benutze ich derzeit als Einziger svn für meine Projekte und kenne mich daher einigermaßen damit aus.
Nun möchte ich generell die Richtlinie ein VCS zu verwenden in der Firma durchsetzen. Dazu lese ich nun schon endlose Seiten im Internet und habe je ein Buch zu svn und Git neben mir liegen. Des öfteren lese ich dass Branching bei svn eher schwierig sei und zu Konflikten führt und das bei Git alles viel "besser" wäre. Nun bekomme ich aber aufgrund der kleinen Mitarbeiteranzahl folgende Problem in meinem Kopf:
Hier gibt es keine "Teams" die sich ausschließlich mit Feature X oder Y befassen, während andere Bugfixes und/oder Testings betreiben.
Soll heissen: Es kann durchaus passieren (sogar Regelfall), das jemand an Feature X arbeitet und dann durch einen nötigen Hotfix schnell umschalten muss um diesen zu beheben. Vielleicht soll er anschließend mal bei einem anderen Mitarbeiter bei Feature Y mit schauen (oder sogar mitarbeiten) bevor er wieder zu Feature X umschaltet und weiterarbeitet. Für mich klingt das ganz stark nach einem komplett zentralem System mit starker Verwendung von Feature-Branches.
Sehr gut finde ich dieses Branching-Model (welches allerdings im Zusammenhang mit Git aufkam): http://nvie.com/posts/a-successful-git-branching-model (obere Grafik). Es spiegelt eigentlich exakt den Prozess wieder den ich mir vorstelle:
- Im Master befindet sich die stabilie ausgelieferte Version.
- Vor Auslieferung wird ein Release-Branch eröffnet der alle Neuerungen für das kommende Release beinhaltet -> Hier könnte man sich z.B. auch Beta-Kunden vorstellen die ein solches Release ausgeliefert bekommen.
- Zum Schluss wird ein stabiles Release in den Master ge-merged und die übrigen Kunden bekommen es automatisiert ausgeliefert.

Nun frage ich mich wieso das nicht auch mit svn machbar sein sollte damit jeder Entwickler zu jeder Zeit Einblick in die anderen Features erhalten kann. Nun könnte man git sicherlich auch so einrichten das alles zentralisiert abläuft - aber warum dann nicht gleich wieder svn nutzen?

Gibt es hier irgend einen Fallstrick den ich einfach nicht sehe bei SVN? Da ich bisher immer nur allein mit svn gearbeitet habe und daher eigentlich auch fast ausschließlich mit trunk arbeitete, kenne ich sicherlich nicht die Problematik die bei mehreren Mitarbeitern beim mergen auftreten können. Grundsätzlich denke ich aber dass die Arbeit der Entwickler im hohen Maße ohnehin disjunkt sein wird. Mach ich mir vll auch nur einen zu großen Kopf um Dinge die kaum auftreten werden?

Besten Dank jedenfalls für Meinungen und Gedankenanstöße!

Martin

[gfoidl]

Hallo,

ich würde (Tortoise-) SVN nehmen, alles was du beschrieben hast und auch was im Bild gezeigt wird, lässt sich damit umsetzen. Probleme sind mir keine bekannt.

Im Link ist übrigens das Argument, dass Branching in den SVN Büchern erst weiter hinten kommt im Gegensatz zu GIT-Büchern, wo es zu beginn kommt, ein Hammer. Das kann doch keine Einflussfaktor für eine Entscheidung sein ;-)

Aber damit du auch andere Meinung einholen kannst, schau dir mal Versionsverwaltung: benutzt ihr verteilte Systeme wie Git, Mercurial, Bazaar? und Alternativen zu Tortoise SVN an.


mfG Gü

[mfernau]

Was im Bild gezeigt wird macht mir derzeit ein paar Schwierigkeiten wie das letzten Endes mit svn abgebildet werden kann.

Würde folgendes Szenario gehen (zur Analogie im Bild)?

trunk: ist der development Zweig. Hier sollte eigentlich nicht direkt comittet werden. Dient quasi nur als merge-target
branch-master: abgespalten von trunk, bekommt stabile Zustände (mittels "svn merge http://.../branch-release-x.y" nach Abschluss der Tests an x.y)
branch-feature-*: (kurz-/langlebige) Feature Entwicklungen - abgespalten von trunk. Enden mit Release/Verwurf des Features
branch-release-*: (kurzlebige) Releasezustände - abgespalten von trunk. Enden mit Release (reintegrate in trunk)

Also:
In trunk befindet sich der Entwicklungsstand. Hiervon werden neue Funktionen abgespalten und wieder Reintegriert (wie im Bild). Wünscht man sich ein neues Release auszuliefern, spalten wir ein branch-release-x.y vom trunk ab und testen es (beta kunden, bug fixes etc..). Nach Abschluss der Tests reintegrieren wir branch-release-x.y wieder zurück nach trunk und mergen es zusätzlich nach branch-master. Anschließend kann man diesen release-banch entfernen. So kommt in branch-master immer nur ein stabiler Zweig und ein automatisiertes build-System kann neue Versionen auf diesem branch zum Kunden ausliefern.
Hotfixes werden von branch-master abgespalten und in diesen nach Abschluss wieder reintegriert.

Könnte das so funktionieren? Im Prinzip bildet es das Szenario aus dem Bild ab. Mit "develop" als trunk, "master" als endloser branch-master und alles andere als kurzlebige branches. Ich denke das klingt irgendwie gut...

Aber so ganz sicher bin ich mir nicht

[fanderlf]

Wir entwickeln hier ganz ohne Feature Branches, ausser für wirklich sehr sehr große Änderungen die fast alle Files anpacken. Wir entwickeln mit FeatureToggles. Das sind praktisch Branches im Code. Kann ich nur empfehlen.
Allerdings klingt das nun bei euch nicht so sonderlich top modern und ich weiss nicht ob eure Entwickler bereit sind mit sowas zu arbeiten.

Zum Thema Git vs SVN: Wenn sich eure Entwickler noch nicht sehr mit VCS beschäftigt haben ist SVN definitiv die bessere Wahl. Dafür gibt es ein schönes grafisches Frontend und zu 90% braucht man eigentlich nur UPDATE und COMMIT. Dazu noch ein merge Tool um evtl. auftretende Konflikte zu beheben. Für Git gibt es momentan kein brauchbares UI und man muss sich gut damit beschäftigen damit man es vernünftig bedienen kann. Und das dann auch nur auf Kommandozeile. Git hat allerdings auch mehr Optionen. Richtig nutzen kann man Git aber auch erst wenn die Entwicklung verteilt erfolgt. Das ist aber bei euch in der Arbeit wohl auch eher nicht der Fall.

Ich würde euch zu SVN raten.

Aber ganz ehrlich: Heutzutage noch ohne ein VCS zu arbeiten ist grob fahrlässig.

[Ralf Jansen]

... und ich weiss nicht ob eure Entwickler bereit sind mit sowas zu arbeiten.

Dem kann ich nur zustimmen. Egal für welches System man sich entscheidet für den Anfang sollte man nicht gleich mit der Endlösung anfangen. Bei nur 4, in diesem Gebiet eher unerfahren, Personen die Wahrscheinlich im selben Büro oder doch zumindest in benachbarten Büros sitzen sollte man auch mit einem simpleren Verfahren starten können und anstehende Problemchen kommunikativ lösen. Nach der Überzeugungsphase kann man dann aufrüsten Sonst ist das Projekt "wir führen ein VCS ein" schon am Anfang vom scheitern bedroht.

[mfernau]

Aber ganz ehrlich: Heutzutage noch ohne ein VCS zu arbeiten ist grob fahrlässig.

Ich weiß. Das Thema Fortschritt in Sachen Entwicklung und Programmierung wird erst durch mich in diese Firma getragen. Hier wurde in den letzten Jahren so einiges schleifen gelassen was die Modernität der Entwicklungszyklen betrifft. Daher möchte ich das gern nachholen und nun etablieren.

Ihr habt vollkommen recht: Der Anfang sollte seicht und einfach sein. Daher ist mein Gedankengang ohnehin stark Richtung SVN ausgeprägt und ich versuche mein geschildertes Szenario mit SVN abzubilden.

Wir sind ein kleines Entwicklerteam, doch leider sitzen nicht alle im selben Büro. Wir haben einen Entwickler der per VPN-Anbindung (über DSL) mit unserem Netzwerk verbunden ist. Es wird sich daher noch herausstellen wie SVN dabei skaliert. Das ist der größte Punkt über den ich mir noch Sorgen mache. Häufige switches werden sollten da vermutlich vermieden werden.

[gfoidl]

Hallo mfernau,

noch ein Punkt der für SVN bei der Einführung von VCS spricht: Du kennst dich mit SVN aus, somit es ist für die anderen leichter wenn Fragen/Probleme auftreten. Sie wissen wem sie fragen können und das ist schon ein großer Vorteil.

Wenn das Grundverständnis für VCS erreicht/vorhanden ist, kann man nach Alternativen suche, wenn mit SVN Probleme auftreten (was ich nicht glaube).

mfG Gü

[fanderlf]

Ja ich denke auch dass SVN wirklich "reicht". So etwas wie GIT braucht man wohl nur wenn man verteilte Szenarien hat wie es z.B. in Open Source Projekten der Fall ist. Wir haben momentan auch SVN und sind eigentlich glücklich damit. Wir hatten auch schon überlegt darauf umzusteigen, weil ein anderes Produkt bei uns mit Git entwickelt wird. Aber wirklich Vorteile hat das für sie im Vergleich zu uns auch nicht.
Git ist halt grad Hype