Pokud chci na to jit pres feature branche, pak je otazkou, z jake vetve se ta feature branch vyrobila. Pokud z hlavni vyvojove vetve (u tebe master), pak se feature mergne zpet do masteru. Pokud se na kazdy novy kod dela feature branch a pokud se by se kazda feature branch mergovala nejen do masteru, ale i do releasu, pak me s dovolenim napada otazka, cim se teda releasy lisi od masteru a cim se vlastne lisi navzajem od sebe?
Pokud jedu systemem, ze mam rekneme ten master jako hlavni vyvoj a pak mam release vetve pro jednotliva vydani a jsem nucen/chci udrzovat par releasu zpet, pak to udrzovani releasu by se melo omezit hlavne na opravu chyb a v krajnim pripade na nejakou upravu/novou funkci. Ano, vim, ze to nezni zrovna akademicky idealne. To ted nechme stranou.
Pokud tedy resim problemy tak jak pisu v predchozim odstavci, pak bych rekl, ze pokud mam pozadavek, abych doplnil novou vec do stare release, pak udelam feature branch z te release, udelam upravu a merguju zpet do release (merge request v gitlabu). Pak je na odpovedne osobe, aby bud hned nebo az casem hromadne mergla veci z releasu do masteru, mozna ze starsiho releasu do mladsiho. Jestli na tohle lze dat merge request nevim, ale rekl bych, ze by to mohlo jit.
Mi osobne tento postup dava nejvetsi smysl, nejvice se to blizi tomu, co je popisovano jako idealni gitflow. Od nej se to de facto lisi jen tim, ze je v jeden okamzik otevreno vice releasu, coz idealni gitflow nevidi rad.
Snazit se delat novinky v masteru a rvat je zpet do releasu mi prijde ponekud nasilne a nechci si moc predstavovat, co to obnasi. V urcitych situacich prece musim temer vse nove z masteru prenest do releasu, takze release je na tom stejne jako master. To mi prijde fakt pri nejmensim divny.
Moc sem asi neporadil, ale hlavne ze sem se vypovidal ;-)
15 Odpovědí
3386 Zhlédnutí