Merge vs. rebase workflow rubrika: Programování: Jiné

2 borekb
položil/-a 21.4.2015

Chci se zeptat na vaše zkušenosti s merge vs. rebase workflow v Gitu (zdůrazňuji zkušenosti, teorii znám). Na webu najdete hodně článků doporučující rebase workflow kvůli čistší historii projektu (viz např. zde nebo zde), ale v menším množství i články doporučující přesný opak (např. zde).

Náš projekt začal (asi typicky) v jednom, dvou vývojářích, kde nám přišlo zbytečné si historii špinit merge commity a rebase workflow fungovalo dobře. Při více lidech už je ale historie taková trochu divná - například deset commitů, na kterých člověk A pracoval před týdnem ve své feature branchi, se najednou v masteru objeví nad čerstvějšími změnami vývojáře B, což vizuálně vypadá divně (ačkoliv chápu, že to zcela odpovídá rebase workflow). Také s tímto workflow mají problém některé nástroje, např. JIRA, která zaindexuje commity jednou ve feature branchi a podruhé v masteru. Opět, je to nejspíš chyba JIRY, ale v praxi to trochu prudí a nemáme na to snadné řešení.

Časté merge jsem měl historicky spíš za zlo, viz např. tento populární obrázek, ale na druhou stranu weby jako GitHub nebo BitBucket jsou na merge workflow postavené a tak si říkám, jestli rebase workflow není v zásadě přežité. Přesto se ale pořád najdou projekty, které i na GitHubu jedou rebase workflow a o svou commit historii se velmi pečlivě starají, viz např. Angular.js (běžný vzhled historie na GitHubu viz např. React.js - něco commitnuté přímo v masteru, něco mergnuté, celkově "bordel", ale je otázka, jestli to vadí).

A tak mě zajímá, pokud někdo máte zkušenost z větších projektů s oběma přístupy, jestli máte nějaké tipy, doporučení, upozornění apod. Co z těchto dvou přístupů se vám osvědčilo lépe? Díky.

odkaz
9 Augi
odpověděl/-a 21.4.2015

Používáme merge-requesty v GitLabu, takže mergujeme. Jedeme striktně novou feature-branch pro každý task z Jiry, přičemž složitost tasků je typicky jednotky hodin, max. jednotky dní, takže feature-branches jsou relativně krátké a tudíž máme minimum konfliktů při mergování - drtivá většina jde udělat na jedno kliknutí z GitLabu (včetně odstranění feature-branche na dvě :-))

Zároveň jedeme continuous delivery, takže nás čistota historie moc netrápí - všechno jde hned do produkce a hned se ví, jestli je to OK. Není důvod se ohlížet.

Ještě před pár měsíci jsem poctivě rebasoval, ale uvědomil jsem si, že je to zbytečná práce - do historie změn se prakticky vůbec nemáme potřebu koukat. Přiroval bych to k rčení "perfektně uklizený dům je známkou promarněného života" :-)

Komentáře

  • skliblatik : ...pročpak je to tady takto komplikovaně, co a v jakém kontextu vlastně ten bývalý kolega tady před 2-mi lety řešil... 22.4.2015
  • Taco : @skliblatik: Jak často něco takového provádíš? Jednou za život? 22.4.2015
  • skliblatik : Není to každý den, ale bohužel častěji, než by mi bylo milé. 22.4.2015
  • Anonym : Asi to nebude nejaký mega zložitý projekt s veľa git repozitármi, keď sa nepotrebujete dívať do histórie.. Naše workflow na mi nechce rozpísovať, vyšlo by to minimálne na jednu A4 ale ma po tých príspevkov ma teší, ako dobre sme to vymysleli. Ale používame merge requesty v gitlabu, ktoré ešte prechádzajú code review. Prípadné code review commity sa squashujú a merge request je rebasnutý na devel branch, prípadne aj nejaké backporty ak sú potrebné. 24.4.2015
  • bretislav.wajtr : @ado21: Naprosto s vami souhlasim... veta "Neni duvod se ohlizet" opravdu neplati vzdy... napr. situace kdy prijdete na projekt, ktery uz tri roky bezi a pracovalo na nem spousta lidi... Annotate a prehledna historie je pak spasa.... 25.4.2015
  • v6ak : Já se občas dívám do historie, ale merge commity by mi asi nějak nepřekážely, když mě zajímá kontext, v jakém se to tehdy dělalo. 29.4.2015

Pro zobrazení všech 8 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.