Git flow rubrika: Nástroje: Verzování

5 anti.cz
položil/-a 15.8. 20:04
 
upravil/-a 15.8. 20:18

Ahoj, mam to dotaz ohledne Git flow. Porad moc nechapu jednotlive kroky mezi vetvemi.

  1. 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.

  2. 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.
odkaz
13 Honza Břešťan
odpověděl/-a 15.8. 21:47
 
upravil/-a 15.8. 21:54

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.

Komentáře

  • anti.cz : @Honza Břešťan "U 2 pozor na jednu vec..." Toho se trosku bojim, ale tyhle problemy by se mely odchytit. F1 a F2 by se do Develu nemely dostat a az se budou nasazavat, tak by to melo shoret v Releasu, kde by uz mel byt F3, ktery byl publikovan v minulosti. Ten "feature toggle" se mi libi, ale dokazu si predstavit, to peklo kam to muze zajit. Na tom Git flow netrvam, protoze se mi to vubec nelibi(libi se mi akorat 4 vrstvy vetvi). Nevidim tam zadny benefit Develop vetve. Master -> Feature -> Release -> Master by byl mnohem flexibilnejsi. Jeste bych chapal, ze si v Develop ostestuji, jak funguji features po spolu, ale tohle si stejne muzu udelat v Release. 15.8. 23:12
  • Honza Břešťan : Jo takhle, ze by se samotne featury vubec nemergovaly do developu a byly jen ve svoji release branchi a pak v masteru? To podle me okamzite narazi pri prvnim vetsim zasahu do developu, pokud Feature treba 2 a 3 budou vychazet ze stejne casti kodu. Feature 3 uz bude v masteru, Feature 2 prida do developu nejaky refactoring, pak v samostatne release branchi prijde ta logika nad tim a pri pokusu zamerogvat ji do masteru se pujdes povesit, protoze to uz nepujde znovu sloucit. Jedine reseni je, ze vsechny featury eventualne skonci v jedne branchi spolu a z toho pak budou vychazet nasledujici featury, jinak bude kazdy release nekonecny merge conflict. Druhy problem pak je, pokud bude potreba delat zmeny do releasnutych featur - ty by slo delat jen v masteru a to ho zase odchyli dal od developu. Nedava mi to smysl ani z podstaty veci - kod bez featury je k nicemu a nejde z nej zjistit, proc je tak, jak je. Dovedu si takovehle rozdeleni predstavit u treba frameworku a aplikaci nad nim, ale to je pak lepsi mit framework ne v jine branchi, ale v jinem repozitari, a publikovat ho stejne jako by byl verejny, cili pres nejaky package management. Pak je vic videt, co je public API a co se muze menit. 16.8. 17:31
  • Honza Břešťan : Co se tyce `Master -> Feature -> Release -> Master`, to muze fungovat v pohode, pokud si budete nechavat ty release branche, aby na nich sly delat hotfixy (pokud je tohle flow potreba). Jinak mi prijde vyhoda samostatneho developu v tom, ze pokud je potreba udelat pro konkretni release nejakou jednorazovou zmenu, tak ta se muze udelat v release branchi, dostane se do masteru a jde k zakaznikum, ale v developu ta zmena nebude. Tim padem pristi release, ktery jde `Develop -> Release -> Master` (nebo jenom Develop -> Master, pokud neni potreba zadna zmena oproti developu), tu jednorazovou zmenu zase odstrani. Pokud by to nebyla jednorazova zmena ale treba fix, tak se muze release branch zamergovat do developu i do masteru, aby to tam pri pristim releasu zustalo. 16.8. 17:34
  • anti.cz : Ted jsem byl pryc, tak to nevim jestli jsem schopny to vstrebat. Zkusim to popsat jeste jinak. F3 se z release vetve nasadim do master a potazmo merguje do develop. Po tomto se F3 vetev a release vetev maze. Master a develop obsahuje kod F3. Nekdy v blizke budoucnosti udelam refactoring v F2 a potom si rebasenu develop do F2, abych ji obcerstvil. A ted nastava problem. Potrebuji recatoring dostat do developu. V soucasne chvili me napada pouze "git checkout d48dsf4sf -- app/some.file" a takhle si vytahat postupne soubory z refactoringu F2 do developu a potom z nich na developu udelat novy commit. A potom co si opet rebasenu develop do F2, tak je otazka co se stane. V obou vetvich budou stejne modifikace, ale v jinych commitech. Problem by byl kdy se mi prodarilo si vytahnout cely commit refactoringu z F2 do release a mel i stejny hash(a to ani nevim jestli vubec jde). Tam by to pak stopro bouchlo. Prepokladam, ze commit hash se generuje na zaklade modifikaci, casu a message atd. 22.8. 20:16
  • Honza Břešťan : Aha, tak to jsem jen blbe pochopil. Hlavni je, ze se F3 dostane i do developu. Pokud je pak soucasti F2 refactoring, ktery se hodi mit v developu jeste predtim, nez se tam pripadne da cela F2, tak se to da treba cherry-pickovat, nebo (pokud nevadi zmeny historie v F2 branchi) se da F2 branch prekopat (treba pres interactive rebase), aby nejdriv obsahovala commity jen s refactoringem, ty se daji normalne mergnout do developu, a az po nich samotnou funkcionalitu feature 2, ktera zustane v te F2 branchi a az pak se to mergne do masteru a do developu. V pripade merge to pak jsou v F3, developu i masteru stejne commity, takze by se s tim git mel umet poprat bez merge conflictu v budoucnu. Cherry pick nebo checkoutovani jednotlivych zmen skonci novym commitem s novym hashem, takze kdyz se pak daji vsechny zmeny dohromady, nektere bude git chtit udelat dvakrat a bude potreba resit conflicty. 22.8. 22:38
  • Michal Kleiner : Jinak pro merge je jedno, ze stejne zmeny jsou v jinych commitech, merge zajima akorat aktualni stav, ne jak se k nemu doslo. 23.8. 6:06

Pro zobrazení všech 7 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.