Utrzymanie projektu - użycie gita

0

Mam taką sytuację, napisałem aplikację, którą ciągle rozwijam, mam na nią kilku klientów. Mam taką sytuację, że aplikacja ma już kilka wersji, załóżmy że v1.0 v2.0 v3.1 itp. Muszę utrzymywać wszystkie wersje, bo u niektórych klientów mam różne wersje, które mogą różnić się np użytym frameworkiem, bo ktoś chciał, żeby była obsługa windows xp a gdzie indziej już nie było tego wymagania więc można było użyć nowsego .net frameworka.

Obecnie wszystko trzymam w osobnych katalogach, łącznie z kolejnymi poprawkami w ramach danej wersji. Pomyślałem zeby użyć do tego gita, tylko nie bardzo wiem jak to rozplanować. Czy poszczególne wersje wrzucać sobie w branche a w głównej gałęzi mieć tylko jak najnowszą wersję, czy jakoś inaczej będzie lepiej.

Doradzcie coś :)

0

To zależy. Myślę, że Git to tylko jeden element układanki.

Jak bardzo wersje się między sobą różnią? Czy jest wydzielony jakiś w miarę stabilny rdzeń i rozwijanie wersji polega po prostu na tworzeniu "dodatków" wokół pewnej wspólnej części? Czy może nie ma nic takiego i projekt jest bardziej monolityczny i rozwijanie kolejnych wersji polega na zmianie całego monolitu, jakim jest projekt?

Myślę, że należałoby zadać pytanie jeszcze "czy obecna struktura kodu pozwala mi łatwo na utrzymywanie i rozwijanie wielu wersji naraz?" (jeśli nie to "w jaki sposób mogę zrefaktoryzować projekt, żeby to umożliwić?"). Albo "czy mogę wydzielić core i rozwijac wspólny core osobno od tego, co specyficzne dla różnych wersji?"

Ja tu więc widzę bardziej pytanie o ogólny stan projektu (architektura itp.).

Ale także o sposób użycia

bo ktoś chciał, żeby była obsługa windows xp a

Czyli pytanie, czy potrzebna jest kompatybilność wsteczna (jeśli tak, to cię może to zwolnić). Co jeśli pewne rzeczy będą musiały być po prostu zamrożone w jakiejś wersji, żeby się nie rozpieprzyło nic u jakiegoś klienta

Czy poszczególne wersje wrzucać sobie w branche a w głównej gałęzi mieć tylko jak najnowszą wersję, czy jakoś inaczej będzie lepiej.

można byłoby zrobić branch master (z rdzeniem apki) i do mastera kłaść tylko rzeczy wspólne, oraz branche poboczne, w których rozwijać osobne gałęzie. Ale te gałęzie codziennie byś integrował (np. git rebase) z masterem, żeby gałęzie były zawsze aktualne.

Tylko nie wszędzie się to sprawdzi.

Poza tym nie trzeba robić gałęzi. Można wydzielić po prostu różne katalogi w repozytorium i mieć jedną główną gałęź, w której zawierałyby się wszystkie wersje.

Można by też jakieś feature flagi umieścić, i przełączać dynamicznie zachowanie projektu

Nie trzeba też wszystkiego trzymać w jednym repo. Można utrzymywać ileś repo (ale niekoniecznie 1 repo = 1 wersja, chodzi mi też, że można wydzielić pewne rzeczy wspólne do innego repo).

Ale generalnie to zależy (w dużej mierze od tego jak bardzo modularny jest projekt. Jak masz monolityczny duży projekt o architekturze kuli błota to będziesz miał ograniczone pole do popisu). No i też co to znaczy "wersja" w tym kontekście?

Generalnie nasuwa mi się więcej pytań niż odpowiedzi.

1

Jedno repo na kod wspólny (jeśli da się taki wydzielić) i oddzielne repozytoria dla oddzielnych aplikacji klientów. Bo to nie są tak naprawdę wersje, mimo że tak je nazywasz, ale po prostu oddzielne aplikacje.

3
Nieposkromiony Szewc napisał(a):

ktoś chciał, żeby była obsługa windows xp a gdzie indziej już nie było tego wymagania więc można było użyć nowsego .net frameworka.

I w ten sposób dorabiasz sobie niepotrzebnej roboty. Trzeba było zacisnąć zęby i trzymać się tej wersji, która chodzi na XP (czyli 4.0)

1 użytkowników online, w tym zalogowanych: 0, gości: 1