Mam pytanie dotyczące pracy z gałęziami GITa. Pracuję nad projektem, który ma gałęzie dev, stage i master.
Prace przebiegają tak, że pracuję na dev lokalnie. Gdy tylko zrobię commit, od razu robię merge z gałęzią stage i push na serwer. W ten sposób na serwerze jest wersja stage to testowania. Po przetestowaniu robię merge dla gałęzi master i push.

I teraz mam kilka wątpliwości:

1. Po co mi właściwie jest ten dev? Nikt niczego nie robi z gałęzią dev projektu online, testy są przeprowadzane na stage. Efekt byłby taki sam gdyby pracować od razu na stage. A więc może czegoś nie biorę pod uwagę?

2. Założenie z dev - stage - master rozumiem tak, że programiści pracują na devie, mergują na stage dla testerów, a potem na master dla użytkowników.
Ale co zrobić w sytuacji, w której chcę się zająć dwoma zagadnieniami równolegle i jedno zakończyłem i chcę pushować, a drugie jeszcze jest w rozsypce i nie chcę go wypuszczać? Mam tą swoją gałąź dev i nie widzę żadnego sposobu żeby to rozwiązać poza tym, żeby prace nad osobnymi zagadnieniami, które mogą nie zostać skończone rozpoczynać na osobnych gałęziach stworzonych tylko pod te konkretne zagadnienia. Ale nie jestem pewien czy to prawidłowe no bo narzucono mi dev-stage-master jak gdyby nie przewidując tworzenia innych gałęzi.

3. Pracuję i pushuję kolejne zrealizowane zadania na stage dla testerów. Po jednym dniu mam tych zadań pushowanych kilkanaście i wersja master jest np. 30 commitów w tyle za stage. I tu mam dwa problemy:

a) Testerzy informują o poprawności kolejnych kwestii i gdyby zatwierdzili wszystkie to mógłbym zrobić merge dla master, ale przecież ciągle przybywa tasków na stage więc ciągle są jakieś nieprzetestowane. Kiedy więc jest dogodny moment na merge dla master skoro zawsze część spraw może być nieprzetestowana?

b ) Gdy już robię merge dla master np. pod koniec dnia to tak naprawdę nie mogę być pewien, że to wszystko działa. Co w takim razie zrobić? Testować ponownie wszystkie taski na master? Boję się zrobić merge i iść spać bo rano może się okazać, że cały serwis leżał przez noc. Gdybym miał nadmiar testerów, którzy pracują całą dobę to mógłbym im dać do testowania wszystkie te zagadnienia tym razem na master. Ale co robić gdy nie mam aż tyle zasobów testujących?

c) Robię merge dla master i kilkanaście zadań wskakuje na serwis online. Zanim każde zostanie przetestowane, nawet gdy mam wbród testerów to część rzeczy może leżeć, a to jest niedopuszczalne. Jak to rozwiązać? Przecież takich zagadnień mergowanych z master może być np. 100 pod koniec dnia jeżeli jest wielu programistów.

Bardzo bym był wdzięczny za naprostowanie mojego z pewnością krzywego spojrzenia na zarządzanie projektem, dzięki

To pytanie raczej kierowałbym do twojego project managera / kierownika / szefa.
My tutaj nie znamy waszej infrastruktury, waszych założeń i podejścia do tworzenia projektów.

Na stan aktualny, tak jak to przedstawiłeś, bez argumentacji istnienia dev
To także uważam podobnie, że wystarczyłyby tylko te dwie zdalne gałęzie.


To jest właśnie piękno GIT, że możesz sobie tworzyć lokalne gałęzie, których wcale nie musisz pushować na serwer.
Pracujesz sobie na nich, a gdy masz wszystko gotowe mergujesz je do lokalnego dev i lokalne dev pushujesz na serwer.

Czyli na przykład wprowadzasz dwie poprawki równolegle, to tworzysz sobie dwie lokalne gałęzie o nazwach fix001 oraz fix002
W jednej wprowadzasz jedną poprawkę, a w drugiej drugą poprawkę, gdy zakończysz pierwszą to mergujesz fix001 z dev i pushujesz
Gdy zakończysz drugą to mergujesz fix002 z dev i także pushujesz.

GIT jest systemem rozproszonym i w swoim lokalnym środowisku możesz sobie tworzyć ile chcesz gałęzi.
Po to, aby pracowało ci się najlepiej jak to możliwe, natomiast to sam efekt końcowy zmergowany pushujesz na serwer.


Dogodny moment jest wtedy, kiedy ty i testerzy skończycie pracę nad tym projektem / zagadnieniem.
Zmiany powinny być wprowadzone po zakończeniu prac nad danym zagadnieniem, a nie na bieżąco (w trakcie).
Tym, bardziej że często zagadnienia są ze sobą powiązane w jakiś sposób.

Wprowadzane poprawki możecie łączyć sobie w pakiety poprawek.
Np. jeżeli otrzymaliście 10 zgłoszeń błędów, to przenieście te wszystkie poprawki jako jeden pakiet.
Uwzględnijcie to zarówno podczas testów jak i podczas developingu - tutaj już musicie się jakoś sami dogadać.


Myślę, że kwestię tego pytania wyjaśnia poniekąd moja odpowiedź do podpunktu a)
Dodam jeszcze, że uważam za konieczne powtórzenie testów po merge na master.


Tutaj także musicie się indywidualnie dogadać i puszczać te zadania mniejszymi partiami (jeżeli nie są one powiązane ze sobą).
Tak jak wspominałem o "pakietach poprawek" puszczacie 1 pakiet - powtórka testów na master, drugi - powtórka testów na master itd.

Super, dzięki za odpowiedzi.

EDIT: po namyśle mam jeszcze jedno pytanie. Czy nie ma sposobu, żeby po przejściu testu na stage robić merge pojedynczego commita z master? W ten sposób w miarę przetestowania elementów mógłbym je mergować. Jeżeli jest to możliwe to jak taka operacja powinna wyglądać przy założeniu trzech gałęzi: dev-stage-master?

Oczywiście możliwość istnieje, ale to już wasza indywidualna kwestia.
Musicie to sobie jakoś ustalić, ponieważ nie da się prawdopodobnie zmergować tylko części commitów.
Merguje się całą gałąź, a od was zależy jak w danym momencie ta gałąź wygląda i z czego się składa.

Dzięki!

My w firmie opieramy się chyba o jeden z najlepszych flow jaki ktoś wymyślił.

Polecam poczytać jeżeli szcze tego nie widziałeś. Rozjaśni też trochę Twoje mentalne dylematy po co i dla czego.
http://nvie.com/posts/a-successful-git-branching-model/

Dzięki, to mi się bardzo przyda.