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.