Strategia GIT dla malego projektu

Witam. W wolnym czasie pracuje nad serwisem internetowym. Do projektu moze dolaczyc sie jeszcze ktos ale nie bedzie w nim wiecej niz 3 osoby. Aktualnie korzystam z GIT'a i Team Foundation Services a sam projekt jest jeszcze w fazie rozwoju.Ogolnie to mam master branch a do kazdej zmiany tworze feature branch- po zakonczeniu pracy branch jest wyslany do TFS gdzie jest budowany i testowany. Kiedy wszystko jest ok merguje z master branch.

Co za tym idzie zastanawiam sie jak to ma wygladac w produkcji? Jakie strategie stosujecie przy malych projektach?

w bitbucket masz prywatne repo za free do 5 userów+sourcetree+po ssh wysyłaj na online testy/produkcję

A co Ci się nie podoba, że chcesz zmieniać pbecne podejście?

Moze zle zadalem pytanie. Jak najlepiej wypuszczac produkt w kolejnych etapach (duze release oraz bug fixy). Opierac wszystko o master czy tworzyc release branches?

Ps: Wybaczcie jesli uzywam koslawej terminologii.

Poczytaj o git flow

Moim zdaniem podejście na zasadzie tworzenia feature/bugfix branchy jest jak najbardziej w porządku. Projekt jest mały i nie ma za bardzo co przekombinowywać.

Pokusiłbym się o robienie release branchy, choćby po to żeby w przypadku gdy znajdziecie jakieś critical bugi łatwo można było zrobić do nich hotfix (do tego też hotfix branch od brancha z releasem), w innym przypadku musielibyście zrobić hotfix z całą aktualną zawartością mastera.

Jak nie przemawia do was robienie release branchy zawsze możecie użyć tagów do poszczególnych commitów, ale wtedy pojawia się taki problem jaki wymieniłem wyżej.

Do projektu moze dolaczyc sie jeszcze ktos ale nie bedzie w nim wiecej niz 3 osoby.

3 osoby to już tłum. Każdy projekt, który jest robiony w więcej niż jedną osobę(a czasem i 1-osobowe projekty tego doświadczają.) może wcześniej czy później popaść w piekło braku integracji. Ficzer-brancze są okej, pod warunkiem, że są szybko scalane do mastera.

Inaczej będziesz miał ficzer brancze, które stoją tygodniami, a przy merdżu będzie mnóstwo konfliktów, a jeśli nie będzie konfliktów, to testy będą się sypać (bo np. ktoś używał modułu X, a przez kilka tygodni moduł X zmienił swoje API, ale na ficzer branczu tego ktoś jeszcze nie uwzględnił). Podejście, że wszystko jest merdżowane jak najszybciej do mastera pozwala przynajmniej na rozsądną integrację i rozwiązywanie problemów jak najszybciej.

Ale z drugiej strony nawet pisząc ficzer brancze można robić rebase do mastera, więc też można jakoś to zintegrować.

Poza tym komunikacja - strategia Git to nie tylko technika, ale też to, w jaki sposób zespół będzie sprawnie się komunikować na temat zmian w projekcie (jeśli nie będzie komunikacji to np. dwie osoby będą robić zmiany, które będą się konfliktować ze sobą).

Organizacja plików i kodu też jest ważna, jeśli kod jest monolityczny albo przypomina big ball of mud to łatwiej o konflikty niż jak kod jest podzielony na sensowne moduły.

feni000 napisał(a):

Pokusiłbym się o robienie release branchy, choćby po to żeby w przypadku gdy znajdziecie jakieś critical bugi łatwo można było zrobić do nich hotfix (do tego też hotfix branch od brancha z releasem), w innym przypadku musielibyście zrobić hotfix z całą aktualną zawartością mastera.

Jak nie przemawia do was robienie release branchy zawsze możecie użyć tagów do poszczególnych commitów, ale wtedy pojawia się taki problem jaki wymieniłem wyżej.

Przepraszam bardzo, ale na czym dokładnie polega problem z fixowagniem bugów z produkcji na masterze? Zbyt dużo działającego softu?

somekind napisał(a):

feni000 napisał(a):

Pokusiłbym się o robienie release branchy, choćby po to żeby w przypadku gdy znajdziecie jakieś critical bugi łatwo można było zrobić do nich hotfix (do tego też hotfix branch od brancha z releasem), w innym przypadku musielibyście zrobić hotfix z całą aktualną zawartością mastera.

Jak nie przemawia do was robienie release branchy zawsze możecie użyć tagów do poszczególnych commitów, ale wtedy pojawia się taki problem jaki wymieniłem wyżej.

Przepraszam bardzo, ale na czym dokładnie polega problem z fixowagniem bugów z produkcji na masterze? Zbyt dużo działającego softu?

Może źle opisałem sytuacje, chodziło mi o przypadek gdy wydaja wersje np. 1, 2, 3. W sytuacji, gdy zaznaczalibyśmy tylko taggami, który commit jest releasem wydaje mi się, że trudniej jest zrobić hotfix do danej wersji, niż gdybyśmy mieli branch na każdy release. W ten sposób łatwiej jest dodać tylko commit z fixem do brancha release, bez wszystkich nowych ficzerów.

No ok, tylko czemu tak? Czemu nie chcemy mieć ficzerów na produkcji jak najszybciej?

Zanim będziesz miał strategię, to potrzebujesz mieć wizję. Jak sam nie wiesz co chcesz, to kto ma wiedzieć co wpływa na wybór strategii? :)

Ilu różnych odbiorców produktu będziesz miał? Nie użytkowników produktu, a odbiorców ( fizycznych instalacji produkcyjnych) ?
Czy chcesz dla tych odbiorców wypuszczać wspólne poprawki? Np. co miesiąc/kwartał/rok?
Czy chcesz wypuszczać poprawki dla wybranych instalacji?
Czy chcesz wypuszczać nowe funkcjonalności dla wszystkich, czy wybranych klientów?
Czy chcesz mieć zgodność wsteczną czy niekoniecznie?

I pewnie masa innych zagadnień, które wpłyną na przygotowanie wariantów strategii i wybór "optymalnej".