Administrace komentářů

On asi neexistuje jediný „správný“ systém. Když budeš hledat „git workflow“, tak najdeš řadu různých způsobů – každý to dělá trochu jinak.

Já tedy používám primárně Mercurial a následující systém:

• Neexistuje žádná větev master/default/stable/devel ani nic podobného.
• Používá se sémantické verzování.
• Větve jsou pojmenované podle major verze tzn. třeba v_1, v_2 atd.
• Vydané verze jsou označeny štítkem (tag) opět dle sémantického verzování, např. v2.0.0, v2.1.0 (tzn. štítky a větve se poznají i podle názvu – větve mají v názvu podtržítko, štítky ne).
• Když se dělá oprava (hotfix, patch nebo jak tomu kdo říká), tak se z příslušného štítku (např. v2.1.0) odkloní nová větev (např. v_2.1) a v ní se vyvíjí a vydané opravy se označují štítkem typu v2.1.1, v2.1.2 atd.
• Opravy se propagují vždy jedním směrem – nahoru – tzn. dělá se merge z větve v_2.1 do v_2, případně pak do v_2.2, v_3, v_3.1 atd. (pokud existují).
• Pokud se má dostat nějaká nová funkcionalita do starších větví (backport), tak to jde přes cherry-pick. Běžné verzovací systémy to bohužel líp neumí, ale naštěstí to není moc časté.
• Historie je posvátná a nesmí se nikdy měnit. Vždy bychom měli být schopní reprodukovat stav ke kterémukoli bodu v minulosti (proto mám taky radši Mercurial než Git). Tohle pravidlo samozřejmě neplatí pro privátní větve jednotlivých vývojářů – tam se běžně dělá rebase, amend nebo libovolné jiné úpravy historie.
• Zda vyvíjet každou funkcionalitu v samostatné větvi (feature branch) je ortogonální otázka a nesouvisí se systémem popsaným výše – tahle větev se prostě odkloní z jiné větve, do které pak změna přijde, případně se chvíli udržuje bokem, dá se přesadit jinam… Obecně považuji za nejlepší vyvíjet každý požadavek (označen číslem z Bugzilly nebo podobného systému) v samostatné větvi. Pak už je ze samotných větví vidět, na základě jakého požadavku byla daná změna provedena. Nicméně někdy je to zbytečně byrokratické, takže je na zvážení, zda to tak dělat vždy nebo jen u větších zásahů do kódu.
• Problém nastává asi jen v případě, kdy je vývoj veden trochu chaoticky a nejdřív se zadá nějaká práce a pak se na poslední chvíli rozhodne, že se to odloží a dá až do příští verze. Tenhle problém ale není specifický pro systém popsaný výše. Úpravy se pak musí buď revertovat a aplikovat znova v jiné větvi. Nebo se tomu dá přecházet tím, že sadu změn udržujeme v samostatné větvi (viz předchozí bod).