Díky za ten GitFlow, to je myslím to co hledám. Je to dost zapeklitá situace, mladý team, nadšený ale nepříliš zkušený, takže s množstvím oprav, změn a forků roste chaos...
Minimalne vyjit z GitFlow je fajn. Urcite mejte jednu vetev, ve ktere mate uzavrene releasy oznacene tagama. Takova vetev je zpravidla master. Zvlast mejte vetev, ve ktere probiha vyvoj, ktery vice mene na nic nehledi a jede dopredu. Takovou vetvi je vetsinou develop. A urcite mejte vetev, ve ktere se resi release. Tedy v momente, kdy si reknete, ze tenhle stav developu chcete pustit do sveta, tak se udela release vetev. V release vetvi uz pak delat opravy a pripadne i nejake nove veci s velkym ohledem na to, ze to uz nekde bezi a ze se fakt nesmi nic vic rozbit atd.
Pokud mozno nedrzte vetve prilis dlouho od sebe. Release je potreba mergovat do developu, ruzne drobne vyvojove vetve zpet do developu ci releasu atd. Pokud dlouho makam na necem, co mam odvetvene z developu, tak si pravidelne merguju z developu do sve vetve.
Je spousta pravidel, co se pry MUSI delat a co se NESMI delat. Kazdy druh sw se pri vyvoji chova krapet jinak a je potreba podle toho git flow ohnout. Napr. se rika, ze release veteve ma byt jedna. Mozna je to realne u nejake appky pro mobil, ale u aplikace pro prumysl je potreba umet pracovat s hlubsi historii a tak se muzou drzet release vetve treba tri.
Hlavne rozum do hrsti a kdyz neco delam s repem, tak idealne prvni lokalne a dokud to v grafu nevypada tak jak chci, tak nedelam push do remote a tak podobne ;-).
16 Odpovědí
5350 Zhlédnutí