No i posiadanie gałęzi integracyjnej developer gdzie hulają testerzy jest opłacalne zanim pójdzie cherry pick do mastera.
cherry-pick
do mastera? To też jakiś wynalazek z GF? Dla mnie brzmi co najmniej niebezpiecznie takie wybieranie losowej zmiany i wrzucanie jej do głównej gałęzi.
Jak masz tylko gałąź główną i future branche to co z integracją systemu?
Nie rozumiem problemu. Robię deploy z gałęzi i testuję.
Co ze zmianami rozwojowymi, które trwają nieco, więcej niż 1 bugfix?
Generalnie, to dopóki ficzer nie jest skończony, to nie jest merdżowany.
No i nad tymi zmianami pracuje 10 devów.
W sensie jeden pisze ify, drugi pętle, trzeci klasy, i tak dalej? Czemu tyle osób nad jednym taskiem? Może lepiej mieć jednego programistę, który zna cały język? ;)
Gdzieś muszą się integrować. Jakby mieli się integrować między swoimi branchami, lub mergować do lokalnego mastera czy inne dziwne rzeczy to każdy robił by to inaczej i była by bieda.
Ale jaka bieda? Jeśli programista A chce się podzielić swoim kodem z innym, to pushuje taką gałąź, programista B ją pobiera i robi swoje rzeczy, jak skończy, to merguje też do niej. Może przedtem nawet zrobić PR dla programisty A. Nie trzeba do tego żadnego certyfikowanego procesu, to się nazywa używanie Gita
.
Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.
Dwie wersje niezależnie rozwijane? To właściwie są odrębne aplikacje, więc bezpieczniej mieć dwa repozytoria.
A jeśli stara jest już nierozwijana, to wystarczy zrobić bugfixa z taga. W GF de facto też się to robi, tylko tagi są na masterze.
A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.
Skoro są takie potrzeby, to prawdopodobnie prościej byłoby podzielić taski sensownie.
Nie mogą tego zostawić na FB bo potrzebują u siebie.
To może przestać używać GitFlow, i wtedy będą mogli zostawić?
niemniej jest nieprawdą, że cały rozwój wszystkich projektów można sprowadzić do mastera + FB.
Oczywiście, że można, bo gdy używa się Gita, a nie jakiegoś procesu, to nie ma żadnych ograniczeń ani zasad nakładanych na gałęzie. Nikt nie mówi, czy taka gałąż ma trwać 1 dzień czy 3 sprinty, czy ma być na jeden task, na dziesięć tasków czy na pół taska, ile osób może z niej korzystać, czy można ją deployować czy nie. Po prostu używa się gałęzi - tego czegoś, dzięki czemu Git jest taki fajny.
A jak nie ma zakazów ani nakazów, to nie rodzi się patologia procesowa.
Z tego, co widzę, to GitFlow już jest na etapie socjalizmu i bohatersko rozwiązuje problemy, które sam stwarza, a do przydaje się, generalnie gdy:
- nie ma CD;
- jest monolit;
- zespół radośnie tkwi w waterfallu;
- i nie zna Gita.
Czyli właściwie najlepiej spełnia swoją rolę jako lampka ostrzegawcza przed większymi problemami.