logisches Handling von Branches in Versionsverwaltungstools
-
wann genau verwende ich einen branch und wann mache ich ein neues repository auf?
änderungen, welche ich testen möchte lasse ich über einen branch laufen.
aber wie sieht es aus wenn ich parallele implementierungen pflegen möchte?beispielsweise habe ich einen kernteil meiner software der irgendwas berechnet und habe nun aber eine version mit gui und eine version die auf einem server als servlet läuft.
wie teile ich das jetzt auf?
gehören diese beiden versionen in verschiedene branches des selben repositorys oder in unterschiedliche repositorys?
-
Sind das denn unterschiedliche Versionen der selben Software? Oder nur zusätzliche Tools für Deine Software?
Ich würde sowas möglichst stark voneinander entkoppeln und in unterschiedliche Repos verpacken. Branches sind für Situationen da, wo es eine gemeinsame Codebase gibt. Also zB. einen Stable-Zweig und einen Entwicklungszweig oä.
Im Fall irgendwelcher GUIs gibt es ja keinen Grund, den Kern Deiner Software zu duplizieren bzw. irgendwelche Anpassungen daran vorzunehmen. Du schreibst einfach ein zusätzliches Tool, das Du auch getrennt versionskontrollierst.
-
hm es ist zumindest sicher, dass die beiden branches sich nicht mehr treffen werden, da die beiden teile zu unterschiedlich sind. nicht wie stable- und devzweig oder sowas, sondern schon grundlegend andere versionen die dauerhaft getrennt bleiben.
der kern ist gleich*, die darstellung (eigenständige application; servlet) unterschiedlich.
allerdings hängen die beiden versionen der software durch ihren kernteil zusammen und haben selbe abhängigkeiten und werden bis auf den kernteil auch parallel weiterentwickelt.werde das gefühl nicht los, dass ich etwas anderes brauche als einen branch, da der kernteil sich ja auch noch weiterentwickelt.
*(bis auf einige anpassungen der jeweiligen darstellung, was ein problem ist)
Application kern < Servlet
was genau meinst du mit
nman schrieb:
Du schreibst einfach ein zusätzliches Tool, das Du auch getrennt versionskontrollierst.
?
meinst du den kern in einem eigenem repo verwalten und entwickeln? dann müsste ich auch die darstellungsversionen in eigenen repos verwalten und den kern dann dort wieder auf .ignore setzen?
-
Naja, wenn Du das schon unbedingt so regeln möchtest, ohne das Projekt wirklich aufzuteilen, dann könntest Du auch mit Submodules oä. arbeiten.
Also den Kern in ein Repo verpacken und dann neue Repos erstellen, in denen Du den Kern als Submodule hinzufügst oder so.
-
Würde auch sagen, in 3 Module aufteilen
- Core
- Servlet
- Applikationund alles drei sollte sein eigenes Repo haben, so kann die Applikation und Servlet immer auf das letzte Stable von Core zurück greifen, wärend simultan an allen drei Modulen weiter entwickelt wird.
Sobald man ein Release machem möchte, zieht man von allen dreien die letzte Stable und Baut das.
-
werde es jetzt in 3 repos verpacken und den kern jeweils als "externe abhängigkeit" hinzufügen.
ist zwar etwas schwammig - da ich dann sehr aufpassen muss zu welcher version der jeweiligen oberfläche welche version des kern gehört, aber immerhin besser als alle 3 entwicklungen nicht richtig auseinander klamüsern zu können.danke euch beiden