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
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
Comment