Jaké používáte git workflow a proč?

Jaké používáte git workflow a proč?
« kdy: 01. 03. 2019, 12:35:48 »
Ahoj,
zajimalo by me jaka git workflow pouzivate.
A pripadne co se vam na kterem libi/nelibi, osvedcilo/vymstilo...

Nemusi jit nutne jen o git, ale ten me zajima nejvic...

Pokud muzete doplnit i detaily o poctu lidi/tymu pracujicich se stejnou codebase budu rad.
A pokud pouzivate git k verzovani i neceho jineho nez zdrojaku taky si to rad prectu.

Diky
« Poslední změna: 01. 03. 2019, 15:00:08 od Petr Krčmář »


Re:Jaké používáte git workflow a proč?
« Odpověď #1 kdy: 01. 03. 2019, 16:24:00 »

Re:Jaké používáte git workflow a proč?
« Odpověď #2 kdy: 01. 03. 2019, 16:57:09 »
Ahoj,
zajimalo by me jaka git workflow pouzivate.
A pripadne co se vam na kterem libi/nelibi, osvedcilo/vymstilo...

Nemusi jit nutne jen o git, ale ten me zajima nejvic...

Pokud muzete doplnit i detaily o poctu lidi/tymu pracujicich se stejnou codebase budu rad.
A pokud pouzivate git k verzovani i neceho jineho nez zdrojaku taky si to rad prectu.

Diky

tym cca 10 až 15 lidí, používáme www.gitblit.com jako "centrální" repository. Máme více produktů-projektů. Na tom hlavním git repozitáři je nás max 10 lidí. Na codreview používáme Intellij Upsource. Nemáme povinné review. Je to na každém z vývojářů jak bude postupovat. Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.

Snažím se aby vše pro daný produkt bylo v jednom git repozitáři a vše co jsme udělali aby bylo aspoň v gitblit jako samostatný repozitář.

Pro vývoj nové verze používáme master branch, před vydáním (záleží jak je potřeba) se master forkne do pre-release branche, když je hotovo, tak se pre-release branch mergne do branche se jmenem production.

Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message. Někomu to nevadí, je rád, že za ním někdo chodí a ptá se na to, proč provedl nějakou změnu. Já dělám remote, takže si to moc nemůžu dovolit. Pokud děláme změny mimo hlaví release. Vytváříme z production branche novou branch se jmenem hotfix-<verze>. Ta se po vydání hotfixu mergne do production a do master. Každý commit do hotfix branche se pomoci cherry-pick "kopíruje" ihned i do master branche.

Ještě je důležité, že celý projekt se dokáže buildnout na jedno tlačítko v jenkins včetně všech tesů, které máme. Ty máme rozdělené do několika jobů a když někdo udělá commit, tak se začne buildit installer, produkt se nainstaluje a pustí se Geb (Selenium) testy. Další job jede paralelně a ten spouští integrační testy, které trvají déle - např. databáze. Další job je jen pro SonarQube - ten se nespouští po každém commitu - zatím. Další job má QA na vytvoření serveru pro manuální testování, než se provede deploy do aws do testovacího prostředí.

Vše je automatizované, V jenkins si u každého jobu je možné vybrat branch a tu buildovat. Je tam hodně kodu Gradle, v Groovy a v Bash. Snažíme se teď přesunout vše do Docker instancí a nahradit Bash scripty Ansible. Používáme i Ansible AWX.

Jako repozitář souborů, jar, npm, pypi, rpm, deb etc. používáme Nexus i jako proxy public repozitářů.

Re:Jaké používáte git workflow a proč?
« Odpověď #3 kdy: 01. 03. 2019, 17:47:30 »
Dekuju za prispevek.

Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.
Takze kazdy v tymu dela push do origin/master? A v origin nejsou feature branches?

Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message.

Tomu nerozumim. Pri merge nejsou videt jednotlive commit messages? A pri rebase jo?

Re:Jaké používáte git workflow a proč?
« Odpověď #4 kdy: 01. 03. 2019, 19:19:53 »
Delali jsme v podstate standard flow ktere vznikne, kdyz od Atllasianu zintegrujes Jiru a Bitbucket:

1. Kazda nova branch nese nazev konkretniho Jira tiketu (hodi se tam automaticky)
2. Po Review se zasadne delal Merge a to do Development branche. Nebylo to vubec zalozene na Rebase.
3. Meli jsme vzdycky 2 Development branche, pro 2 releasy. Nejake zmeny sly totiz do drivejsiho releasu a nejaka az do toho dalsiho.
4. V Master branchi jsme meli Release.
5. Kazdy merge do Development branche musi byt kompletni a plne funkcni zmena.

Zadna veda. Podle me neni uplne dulezite samotne flow, je dulezite to, aby v tom nebyl mrdnik - musi byt jasne dana pravidla a ty kazdy vyvojar dodrzuje.
« Poslední změna: 01. 03. 2019, 19:23:21 od prihlaseny_uzivatel »


Re:Jaké používáte git workflow a proč?
« Odpověď #5 kdy: 01. 03. 2019, 19:36:53 »
Dekuju za prispevek.

Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.
Takze kazdy v tymu dela push do origin/master? A v origin nejsou feature branches?


Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message.

Tomu nerozumim. Pri merge nejsou videt jednotlive commit messages? A pri rebase jo?


Ne nepouzivame feature branches. Teda neni to pro kazdou ficuru, sem tam se rozhodneme, ze neco zustane nejaky cas bokem, ale to je vyjimecne.

Pri merge musite udelat squash vsech lokalnich commitu do jednoho, pokud chcete mit aspon trochu "linearni" historii. Merge jako takovy jsem nedelal uz hodne dlouho. Pouze kdyz delame release a delame merge do production branch.

Rebase nejdrive odstrani vsechny lokalni commit zaznamy a prida nove commit zaznamy z origin a pak znova "prehraje" moje lokalni commit zaznamy. Toto nejde pouzit, kdyz na jedne branch pracuje vice lidi.

Mame vlastne jen jednu feature branch a to je master. Do ni vsichni integruji zmeny co nejdrive.

Proste nejak zacnete. Bude to bolet obzvlast, pokud prechazite z CVS, ale stoji to za to.

Re:Jaké používáte git workflow a proč?
« Odpověď #6 kdy: 01. 03. 2019, 19:41:18 »
Delali jsme v podstate standard flow ktere vznikne, kdyz od Atllasianu zintegrujes Jiru a Bitbucket:

1. Kazda nova branch nese nazev konkretniho Jira tiketu (hodi se tam automaticky)
2. Po Review se zasadne delal Merge a to do Development branche. Nebylo to vubec zalozene na Rebase.
3. Meli jsme vzdycky 2 Development branche, pro 2 releasy. Nejake zmeny sly totiz do drivejsiho releasu a nejaka az do toho dalsiho.
4. V Master branchi jsme meli Release.
5. Kazdy merge do Development branche musi byt kompletni a plne funkcni zmena.

Zadna veda. Podle me neni uplne dulezite samotne flow, je dulezite to, aby v tom nebyl mrdnik - musi byt jasne dana pravidla a ty kazdy vyvojar dodrzuje.

Ten finalni merge do devel branch to byl squash, nebo normalni merge?
Pokud normalni merge, jak se vam dari orientovat v historii?
Už je to par let, co jsme se rozhodli, ze budeme delat bud squash nebo rebase, protoze vysledna historie vypadala jako nadrazi a nedalo se v tom vubec orientovat. Zlepsilo se to, nebo to proste neresite a zvykli jste si na slozitejsi historii?

alex6bbc

  • *****
  • 1 431
    • Zobrazit profil
    • E-mail
Re:Jaké používáte git workflow a proč?
« Odpověď #7 kdy: 01. 03. 2019, 19:49:04 »
Slozita historie v gitu aspon ukazuje realitu.
dulezite body zmen bud v tagach nebo changelogu.
nemam rad kdyz se historie smrskne na jeden bod v historii.

Re:Jaké používáte git workflow a proč?
« Odpověď #8 kdy: 01. 03. 2019, 19:54:36 »
Tak tady do toho i keca release model

Udrzujou se stary releasy? Pak bude potreba branch pro kazdy release (a opravy pak mergovat ze starych do novych)
Jestli master = stable nebo master = devel head zalezi na okolnostech projektu, jsou situace, kdy dava vetsi smysl to, jindy to druhy
Pro kazdy release tag, changelog se hodi generovat z commitu referencovanych na tickety (jednoduchy a snadna udrzba)

Jinak review pred mergnuti, v Gitlab CI se na Merge Requesty spustej automaticky testy a lze odchytit radu potencialnich problemu, nez se rozbije to nekomu dalsimu. Pro topic branche pouzivame v Gitlabu forky
Merge vs Rebase: preferuju merge: commity pak vzdy obsahuji to, co dany vyvojar skutecne udelal, mirne slozitejsi historie nevadi

Nazvy branchi u nas nijak standardizovany nejsou, ale mym zvykem je to delat podle ticketu - vis ktera rozdelana prace k cemu patri a kdyz je potreba se k necemu vratit rozdelanymu, vim, kde to mam. Jinak commit by mel vzdy nejakym (v tymu standardizovanym) zpusobem bejt navazanej k ticketu, ke kterymu se vztahuje. Casto u projektu, hlavne kdyz uz jsou dlouho vyvijeny, se "blamuje", aby se zjistilo, proc se to tehda zrovna delalo tim urcitym zpusobem, jakym to je udelany.

Jinak za sebe muzu doporucit Gitlab

Re:Jaké používáte git workflow a proč?
« Odpověď #9 kdy: 01. 03. 2019, 21:14:30 »
Dekuju za prispevek.

Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.
Takze kazdy v tymu dela push do origin/master? A v origin nejsou feature branches?


Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message.

Tomu nerozumim. Pri merge nejsou videt jednotlive commit messages? A pri rebase jo?


Ne nepouzivame feature branches. Teda neni to pro kazdou ficuru, sem tam se rozhodneme, ze neco zustane nejaky cas bokem, ale to je vyjimecne.

Pri merge musite udelat squash vsech lokalnich commitu do jednoho, pokud chcete mit aspon trochu "linearni" historii. Merge jako takovy jsem nedelal uz hodne dlouho. Pouze kdyz delame release a delame merge do production branch.

Rebase nejdrive odstrani vsechny lokalni commit zaznamy a prida nove commit zaznamy z origin a pak znova "prehraje" moje lokalni commit zaznamy. Toto nejde pouzit, kdyz na jedne branch pracuje vice lidi.

Mame vlastne jen jednu feature branch a to je master. Do ni vsichni integruji zmeny co nejdrive.

Proste nejak zacnete. Bude to bolet obzvlast, pokud prechazite z CVS, ale stoji to za to.

No my ted pouzivame squash and rebase...
Kazda story = jeden squashed commit
rebase na origin/master a push

A pred par lety jsme pouzivaly takove to atlassian workflow jak popsal prihlaseny_uzivatel.

A jeste drive jsme pouzivali v bit bucketu forky a kazdy si vyvijel co chtel a jeden vyvoleny spravoval repo ze ktereho se buildovalo a mergoval pull requesty kdyz se mu chtelo...

Kazde melo svoje pro a proti...

forky => snadna sprava vice release branches/ hrozny opruz s merge konflikty protoze vyvoleny napred zamergoval neco jinyho a musel se upravovat PR
atlassian => Snadny nastaveni CI - na kazdy PR probehly integracni testy a pritom se to nemuselo nastavovat kazdymu vyvojari na jeho repository
squash and rebase => Nevim presne proc, ale zda se mi, ze mnozstvi merge konfliktu se blizi nule (mozna za to nemuze git workflow, ale architektura projektu + male stories)/ kdyz chci proste nasypat lokalni zmeny na remote, aby se neztratily protoze mi vybouchne disk nestaci proste commit a push, ale musim commit - squash - rebase - push

No a me nejvic zajimaji ty merge konflikty...
Je mozny, ze proste to workflow vede k mensimu mnozstvi konfliktu? Pozorujete to taky?

Co se tyce historie tak je mi celkem jedno jestli vypada jako nadrazi nebo ne. Zas tak casto se do ni nedivam a kdyz jo tak nezacinam od grafu, ale spis od konkretniho commitu. Najdu posledni zmenu radku ktery me zajima a divam se na ostatni soubory ve stejnem commitu a jdu od nich do budoucnosti celkem linearne.



Re:Jaké používáte git workflow a proč?
« Odpověď #10 kdy: 01. 03. 2019, 23:50:52 »
Dekuju za prispevek.

Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.
Takze kazdy v tymu dela push do origin/master? A v origin nejsou feature branches?


Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message.

Tomu nerozumim. Pri merge nejsou videt jednotlive commit messages? A pri rebase jo?


Ne nepouzivame feature branches. Teda neni to pro kazdou ficuru, sem tam se rozhodneme, ze neco zustane nejaky cas bokem, ale to je vyjimecne.

Pri merge musite udelat squash vsech lokalnich commitu do jednoho, pokud chcete mit aspon trochu "linearni" historii. Merge jako takovy jsem nedelal uz hodne dlouho. Pouze kdyz delame release a delame merge do production branch.

Rebase nejdrive odstrani vsechny lokalni commit zaznamy a prida nove commit zaznamy z origin a pak znova "prehraje" moje lokalni commit zaznamy. Toto nejde pouzit, kdyz na jedne branch pracuje vice lidi.

Mame vlastne jen jednu feature branch a to je master. Do ni vsichni integruji zmeny co nejdrive.

Proste nejak zacnete. Bude to bolet obzvlast, pokud prechazite z CVS, ale stoji to za to.

No my ted pouzivame squash and rebase...
Kazda story = jeden squashed commit
rebase na origin/master a push

A pred par lety jsme pouzivaly takove to atlassian workflow jak popsal prihlaseny_uzivatel.

A jeste drive jsme pouzivali v bit bucketu forky a kazdy si vyvijel co chtel a jeden vyvoleny spravoval repo ze ktereho se buildovalo a mergoval pull requesty kdyz se mu chtelo...

Kazde melo svoje pro a proti...

forky => snadna sprava vice release branches/ hrozny opruz s merge konflikty protoze vyvoleny napred zamergoval neco jinyho a musel se upravovat PR
atlassian => Snadny nastaveni CI - na kazdy PR probehly integracni testy a pritom se to nemuselo nastavovat kazdymu vyvojari na jeho repository
squash and rebase => Nevim presne proc, ale zda se mi, ze mnozstvi merge konfliktu se blizi nule (mozna za to nemuze git workflow, ale architektura projektu + male stories)/ kdyz chci proste nasypat lokalni zmeny na remote, aby se neztratily protoze mi vybouchne disk nestaci proste commit a push, ale musim commit - squash - rebase - push

No a me nejvic zajimaji ty merge konflikty...
Je mozny, ze proste to workflow vede k mensimu mnozstvi konfliktu? Pozorujete to taky?

Co se tyce historie tak je mi celkem jedno jestli vypada jako nadrazi nebo ne. Zas tak casto se do ni nedivam a kdyz jo tak nezacinam od grafu, ale spis od konkretniho commitu. Najdu posledni zmenu radku ktery me zajima a divam se na ostatni soubory ve stejnem commitu a jdu od nich do budoucnosti celkem linearne.

To co popisujes delame na projektu prave ted:

1. Mame jen Master branch
2. Kazdy commit predstavuje malou zpetne kompatibilni inkrementalni zmenu
3. Kazda commit ma svou Jiru a jmenuje se presne podle ni.
4. Nedelaji se Merge, ale Rebase.
5. Kazdy commit je releasovatelny.

Vyhoda je, ze:

1. Historie je mene ukecana.
2. Je to velice pohodlna a systematicka metodika nejen pro Git, ale i pro cely proces vyvoje.
3. Celkove mi to prijde cistsi nez metodika Margu v Attlasianu.

Zezcatku jsem lamentoval, ze se tim pro me jako pro vyvojare ztrati developerska historie, takove ty male dilci commity v branchi ktere vysvetluji zmeny, ktere jsem udelal. Ale fakt je ten, ze to nevadi, protoze to motivuje k tomu, aby Jiry byly male a implementace celeho Supertasku byla dobre dekomponovane na casti.

Ale nedelam s tim jeste dost dlouho, abych posoudil nevyhody. Kazdopadne je to velice dobra metodologie a jestli nekdy narazim zase za Mergovani, tak si budu tezko zvykat.
« Poslední změna: 01. 03. 2019, 23:57:42 od prihlaseny_uzivatel »

Re:Jaké používáte git workflow a proč?
« Odpověď #11 kdy: 02. 03. 2019, 13:02:29 »
@prihlaseny_uzivatel: pokud mas podporovat i stary verze, tak ten tvuj model proste pouzit z principu nejde a musi se mergovat, ten tvuj postup funguje jenom na ten tvuj specifickej release model

Re:Jaké používáte git workflow a proč?
« Odpověď #12 kdy: 02. 03. 2019, 13:54:29 »

Kit

  • *****
  • 704
    • Zobrazit profil
    • E-mail
Re:Jaké používáte git workflow a proč?
« Odpověď #13 kdy: 02. 03. 2019, 14:11:09 »
Když dělám sám na nějakém menším projektu, tak si často vystačím s jednou větví master. Má to však nevýhodu, že historie je dlouhá a nepříliš přehledná. Proto si brzy upravím flow tak, že vytvářím tématické větve a ty teprve merguji do masteru.

Zásadou je nikdy nedělat rebase ani ff do masteru.

Re:Jaké používáte git workflow a proč?
« Odpověď #14 kdy: 02. 03. 2019, 15:55:39 »
@prihlaseny_uzivatel: pokud mas podporovat i stary verze, tak ten tvuj model proste pouzit z principu nejde a musi se mergovat, ten tvuj postup funguje jenom na ten tvuj specifickej release model

Ano, to nefunguje. Ale neni to b zadnem pripade specificky release model, je to asi snad ten nejpouzivanejsi model na backendu pri continuous integration.