Git flow rubrika: Nástroje: Verzování
5
anti.cz
Ahoj, mam to dotaz ohledne Git flow. Porad moc nechapu jednotlive kroky mezi vetvemi.
-
Tak jak jsem pochopil, ze by se melo pouzivat: Feature vytvorim z Develop, pokud je Feature hotova tak se s merguje s --no-ff do Develop. Pote vytvorit z Develop vetev Release a pak merge --no-ff Release do Master. Tam tomto nechapu jednu vec. Mam Feature1, Feature2, Feature3, vsechny jsou hotove a tak je mergenu do Developu. Ale vedeni se rozhodne, ze chece releasnout jen Feature3 a ostatni ne. Co ted? Jak to chapu, tak kdybych v tomto bode udelel vetev Release z Developu, tak tam protahnu i Feature1 a Feature2.
- Co mi dava vetsi smysl. Feature vytvorim z Develop. V pripade, ze je Feature hotova. Vytvorim Release z Developu a mergnu tam pouze Feature3 to pak do Master. V tomto pripade Develop slouzi pro distribuci modifikaci jako je napr.: refactoring nebo nejake service v aplikaci, kterou jsem vytvoril ve Feature1 a potrebuji ji ve Feature3 a je mi jedno s kterou Featurou to pujde do Master. V podstate do Develop davat interni mini-feature, ktere nemaji zadani od vedeni, ale slouzi pro programatory. Mohou vzniknout cilene, nebo jako vedlejsi produkt Feature.
- Mozna mi jen unika vyznam --no-off, ale co jsem pochopil, tak je to jen kvuli grafum.
- Prubezny rebase jsem v popisu vynechal.
9
Honza Břešťan
1 chapes spravne. Pokud dela vedeni takovahle rozhodnuti, pak git flow mozna nebude nejlepsi proces a neco jako #2 muze davat vetsi smysl. Branchovaci model je jenom nastroj, jak vyhovet pozadavkum produktu - ne kazdy musi nutne vyhovovat, neexistuje one size fits all proces.
U 2 pozor na jednu vec: kdyz se budou featury zvlast mergovat do release a develop branche, ktere se meni s jinou frekvenci, muze dojit k merge conflictum na jedne nebo druhe strane. Ty s sebou muzou prinest chyby, ktere se projevi jenom na jedne branchi. Takze se muze stat, ze v releasu A, kde je jenom Feature 3, funguje vsechno spravne, ale po zamergovani do developu, kde je navic Feature 1 a 2 a nejaky vetsi refactoring, se objevi ve Feature 3 problem, ktery to uzivatelum v nasledujicim deploymentu rozbije. Samozrejme cim vic automatizace, tim mensi riziko, ale ne kazdy ma 100% pokryti automatickymi akceptacnimi testy...
Pokud stejne trvas na git flow, tak jde v pripravene release branchi bud revertovat zmeny pro Feature 1 a 2, nebo nejakou malou upravou v kodu ty featury "odriznout". To se obcas da u mensich featur, ale nedoporucoval bych to jako obecny postup.
Dynamictejsi alternativa je kazdou feature delat s konfiguracnim prepinacem, AKA feature toggle (nejbliz to bude mit k "release toggle"). Pak je ale stejne potreba testovat, ze featury se spravne zapinaji/vypinaji a ze vypnute Feature 1 a 2 neovlivni funkcionalitu Feature 3. Pokud jich je hodne a ziji v codebase dlouho, muze z toho byt slusne konfiguracni peklo, ale pokud se to pouziva jen pro potlaceni nejake featury na jeden dva releasy, da se to. Na soucasnem produktu pouzivame release feature toggles pro zajisteni kompatibility a snadneho fallbacku v pripade problemu po releasu a zatim to funguje dobre. Nedelame to ale pro kazdou feature - jen tam, kde chceme oddelit deployment od releasu, nebo schvalne integrovat nedodelane featury pro usnadneni mergovani ostatnim. Taky si davame pozor, aby tam prepinace a s nimi spojena slozitost nezustavaly dyl, nez je potreba. Jakmile je releasnuto a vime, ze neni potreba nejaky SOS rollback, tak to hned v dalsim sprintu vycistime.
Tohle pak celkem prirozene vede tak jako tak k opusteni git flow a praci primo v masteru, kde kombinace feature toggles a automatickych testu staci k tomu, aby byl master kdykoliv pripraveny k deploymentu, i pokud je nejaka prace zrovna rozdelana. Chce to mnohem vetsi disciplinu, ale zase odpadne spousta problemu. Osobne ale takhle daleko nejsem a v teamu pouzivame Scrum + git flow.
Pro zobrazení všech 7 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře