GIT model pri prechodu z SVN na GIT rubrika: Nástroje: Verzování
5
anti.cz
Abych to nadhodil. V minule praci byl Git samozrejmosti. No, ale v nove praci to bylo(je) zajete SVN. Po roce a pul nadavani, breceni, vyhrozovani a vseho mozneho se deji zazraky. Nastesti admini stoji za mnou, takze nasazeni Gitu jako takoveho je v pohode.
Prvni vetsi vec, kterou resim je Git model pro lidi, kteri maji celkem vlazny pristup ("no tak teda jo no...") Rozhodl jsem se pro tento http://blogpro.toutantic.net/wp-content/uploads/2012/01/anothergitflow.png. Pouzivali jsme ho v minule praci a celkem mi to s nim vyhovovalo. Ted to bude jeste jednodusi, proteze nebude release vetev. Freature vetev vzdy z masteru. Pokud je featura hotova merge s develem a pote feature vetev merge s masterem.(Z develu nikdy nic nejde do masteru). Je to pro vyvoj vetsiho shopu. Soustavne pridavani a odebirani v zasade mensich veci.
Proc tento:
1) moc se mi nelibi a hodne v Git modelech vidim, ze nova feature vetev se dela z devel vetve
2) devel se prezentuje k rozdelane praci a muze tam byt neco co se ve finale nikdy nedostane na ostrou(souvisi s jednickou)
3) je mozne v podstate kdykoli devel vetev zahodit a udelat znova(vzdycky se tam casem dostane neco co tam byt nema a "nikdo" nevi jak se to tam dostalo)
Pokud mate nekdo zkusenosti s takovym pripadem nebo znate jednodussi model moc dekuji za radu.
Rok a pul jsem s Gitem nedelal a mozna jsem si ukousl trochu vetsi kus, ale nechci to vzdat...
EDIT: doted se SVN pouziva v podste pouze jako zaloha. Jedno repo a jeden trunk nebo jak se tomu v tom nadava.
EDIT2: Jeste resim kam pushovat osobni commity(featury). Pred tim se tohle nemuselo resit, protoze localy se nepouzivaly a kazdy mel svuj vyvoj a ten denne zalohoval. Napadlo me, ze kazdy muze mit svoje repo a na to si udela v remote druhy origin a bude to tam posilat pri commitu feature, ale prijde mi to dost tezkopadny.
6
kluvi
Popíšu jak jsme řešili my, byl to taky porod :) Na GIT server používáme Bitbucket, většina věcí ale půjde udělat i na čemkoliv jiném. My tam máme koupený plugin na sychnronizaci GIT <-> SVN. SVN pak používáme na update na serverech, protože nejdřív potřebujeme updatnout jen některé soubory (SQL scripty, které se pak pustí a pak až se updatne zbytek), což v GITu nejde úplně jednoduše. Releasy nové verze děláme pravidelně cca co 14 dní.
Když jsme rozhodli přejít na GIT, prostě se nastavila synchronizace GIT master <-> SVN trunk. Pak se vytvořila z masteru větev devel a v podstatě bylo hotovo. Na serveru se pak zakázal push do master+devel. Tj veškeré úpravy musí jít vždycky přes pull-requesty. Ty jsou nastavené tak, že je musí schválit aspoň 1 člověk, dá se nastavit i další podmínky (úspěšný build,...).
Chci vytvořit novou funkci, co se nemusí dávat na server hned, ale až v dalším releasu:
- vytvořím feature-branch z developu
- commitnuju, pushuju si do větve
- mám hotovo, vytvořím pull request feature-branch -> develop
- ten se pak schválí a mergne
Na serveru je průser:
- vytvořím hotfix-branch z master
- commituju, pushuju
- pull request hotfix-branch -> master
- server je nastavený tak, že pull requesty do masteru automaticky merguje i do develu
Výhody:
- nestane se mě nikdy, že bych měl master před develem, protože se mě to merguje autmoaticky
- je to blbuvzdorný, protože se to dělá samo a nezapomene se tak hotfix mergnout do develu
- server jde kdykoliv updatnout, protože master = to co je na serveru
- release branche aktuálně nepoužíváme, přišla mě to pro začátek už komplikace
- feature-branch je prakticky to stejné co bugfix (oprava chyby, která není fatální a počká do releasu)
- zjednodušeně - chci to na server hned => dělám větev z masteru, počká to do releasu? => z developu
- každou úpravu vidí aspoň 1 další člověk (pokud to není idiot, co to automaticky approvne)
Nevýhody:
- ještě jsme na žádnou nenarazili :)
Pro zobrazení všech 5 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře