Ok, kloge programmeringshoveder: Jeg har min ebogsinator, v1.
-
Ok, kloge programmeringshoveder:
Jeg har min ebogsinator, v1.
Jeg har planer for en gennemgribende omskrivning, v2, som nok ikke beholder så meget af den originale kode.Hvordan ville I gribe det an, rent praktisk - arbejde i en git branch, lave en fork eller bare et helt nyt repo og så manuelt importere de kodestumper, der giver mening?
Jeg har ingen faglig programmeringsbaggrund, så måske er det indlysende hvis man har det, jeg er bare i tvivl.
@infonauten Helt nyt og manuelt
-
@infonauten Når det bare er dig kan du jo gøre præcist hvad du finder lettest - der er ikke krav om sporing, etc
Medmindre du er ekspert i at arbejde med branches ville jeg bruge et nyt repo.
Husk at sætte backup af det nye repo op også.
@holsta jeg spørger også fordi jeg ikke ved hvad der vil være lettest, jeg har aldrig gjort noget som det her før og måske er der nogle faldgruber jeg ikke kan se. Jeg hælder også selv mod nyt repo.
-
@infonauten Helt nyt og manuelt
@ondekvinde modtaget.
-
@holsta jeg spørger også fordi jeg ikke ved hvad der vil være lettest, jeg har aldrig gjort noget som det her før og måske er der nogle faldgruber jeg ikke kan se. Jeg hælder også selv mod nyt repo.
Jeg har altid fortrudt, de gange hvor vi har prøvet at holde det i samme repo. Så jeg er enig med de andre :).
-
Ok, kloge programmeringshoveder:
Jeg har min ebogsinator, v1.
Jeg har planer for en gennemgribende omskrivning, v2, som nok ikke beholder så meget af den originale kode.Hvordan ville I gribe det an, rent praktisk - arbejde i en git branch, lave en fork eller bare et helt nyt repo og så manuelt importere de kodestumper, der giver mening?
Jeg har ingen faglig programmeringsbaggrund, så måske er det indlysende hvis man har det, jeg er bare i tvivl.
@infonauten Det kommer også an på om du vil have glæde af omskrivningerne efterhånden som du laver dem, eller du vil køre med V1 hele vejen indtil V2 er klar.
-
Jeg har altid fortrudt, de gange hvor vi har prøvet at holde det i samme repo. Så jeg er enig med de andre :).
@tofticles @holsta modtaget.
-
@infonauten Det kommer også an på om du vil have glæde af omskrivningerne efterhånden som du laver dem, eller du vil køre med V1 hele vejen indtil V2 er klar.
@decibyte det kan jeg ikke helt finde ud af, men det er meget vigtigt at v1 kører uden shenanigans indtil v2 er klar til at afløse.
-
@holsta jeg spørger også fordi jeg ikke ved hvad der vil være lettest, jeg har aldrig gjort noget som det her før og måske er der nogle faldgruber jeg ikke kan se. Jeg hælder også selv mod nyt repo.
@infonauten @holsta alle genvejene i git mm er kun genveje, når man kender dem og bruger dem ofte nok til at kunne huske dem, det er i hvert fald min erfaring. Men git er godt, nærmest uundværligt for mig
-
@infonauten Et forslag så: Samme repo. Så kan de evt. dele de ting der allerede er gode og/eller V2 kan nemt midlertidigt låne ting fra V1 indtil du har Ny&Bedre Komponent på plads.
V2 bor særskilt. Begge kan afvikles ved siden af hinanden.
Og...
Medmindre det er et fundamentalt arkitekturmæssigt paradigmeskift, så overvej om du i stedet for at arbejde mod V2, kan opgradere dele af V1 hen ad vejen og helt slippe for at forholde dig til versioner som sådan.
"Version 2.0" bliver meget nemt en mytisk størrelse man aldrig når frem til, fordi den pr. definition tilhører fremtiden. Du vil gerne høste frugten af dit arbejde så snart du har lavet det. Og at vedligeholde 2 versioner af et produkt parallelt giver hurtigt dobbelt arbejde.
-
@decibyte det kan jeg ikke helt finde ud af, men det er meget vigtigt at v1 kører uden shenanigans indtil v2 er klar til at afløse.
@infonauten Et forslag så: Samme repo. Så kan de evt. dele de ting der allerede er gode og/eller V2 kan nemt midlertidigt låne ting fra V1 indtil du har Ny&Bedre Komponent på plads.
V2 bor særskilt. Begge kan afvikles ved siden af hinanden.
-
Og...
Medmindre det er et fundamentalt arkitekturmæssigt paradigmeskift, så overvej om du i stedet for at arbejde mod V2, kan opgradere dele af V1 hen ad vejen og helt slippe for at forholde dig til versioner som sådan.
"Version 2.0" bliver meget nemt en mytisk størrelse man aldrig når frem til, fordi den pr. definition tilhører fremtiden. Du vil gerne høste frugten af dit arbejde så snart du har lavet det. Og at vedligeholde 2 versioner af et produkt parallelt giver hurtigt dobbelt arbejde.
@decibyte uh, det er også nogle gode pointer. Tak.
-
@holsta jeg spørger også fordi jeg ikke ved hvad der vil være lettest, jeg har aldrig gjort noget som det her før og måske er der nogle faldgruber jeg ikke kan se. Jeg hælder også selv mod nyt repo.
@infonauten I hverdagen vil det nok være træls for dig at skulle skifte mellem branches og/eller worktrees.
Nogle af os har brugt versionsstyring siden RCS, men vi er defekte afvigere og skal ikke bruges som beslutningsgrundlag.
-
Ok, kloge programmeringshoveder:
Jeg har min ebogsinator, v1.
Jeg har planer for en gennemgribende omskrivning, v2, som nok ikke beholder så meget af den originale kode.Hvordan ville I gribe det an, rent praktisk - arbejde i en git branch, lave en fork eller bare et helt nyt repo og så manuelt importere de kodestumper, der giver mening?
Jeg har ingen faglig programmeringsbaggrund, så måske er det indlysende hvis man har det, jeg er bare i tvivl.
@infonauten
Der er ikke noget rigtigt eller forkert, det er et spørgsmål om arbejdsmetode.Jeg plejer at lave et nyt repo til en ny version, men det er mest for at min hjerne kan separere to versioner, når de er arkitekturmæssigt forskellige, og så har jeg det gamle liggende i en "Subprojects"-mappe ...
Hvis du stadig laver opdateringer på det gamle projekt, bugfixes osv, så er det måske fordelagtigt at referere til det gamle repo som et submodule, så alle ændringer kommer med "automagisk".
Jeg finder det bare bøvlet at arbejde med submodules, vil helst bare hive "code snippets" over manuelt.
https://git-scm.com/book/en/v2/Git-Tools-Submodules--- Metode 2: Branches ---
Du kan også sagtens have versionsopdateringer til at leve i en separat branch - det har Umbraco-projektet f.eks.Der er en række release-branches til de udgivne versioner, og så er der "dev"-branches til den aktuelle kodebase. For de har indimellem behov for at backporte ting, såsom sikkerhedsopdateringer
