ReviewCode, verzování, commity,... rubrika: Nástroje: Verzování

4 pilif
položil/-a 24.10.2016

Zdravím ve spolek,
měl bych asi takovou obecnější otázku.
Jak řešíte postup s "commitováním"/verzováním, ReviewCode a případnými kontrolami?
Jde mi konkrétně o to:

  1. jestli je vhodnější dělat řekněme spoustu malých commitů s možností detailního procházení, ale zase asi s problémem hromady údajů ve VCS.
  2. anebo raději udělat nějaký větší commit jako celek, který se jeví ve VCS tak nějak konzistentně, ale zase hůře se prochází změny v kódu.

Přijde mi vhodnější bod 1, ale nemám s tím praktické zkušenosti v rámci většího týmu (5 a více vývojářů). Případně jsou nějaké vhodnější postupy?

PS
A co povinnost "push" na konci práce (typicky pracovní doby, je-li) nějaká?

Díky za info.

odkaz
9 Honza Břešťan
odpověděl/-a 25.10.2016
 
upravil/-a 25.10.2016

Tohle docela zalezi na samotnem VCS a jeho moznostech. Vysvetlim:

Na jednom projektu pouzivam git s Bitbucket serverem, plus minus git-flow proces, takze na kazdou zmenu feature branch a pak PR, ktery nekdo zkoukne, approvne a mergne v Bitbucket rozhrani. Vetsinou je ten PR uz po squashnutych commitech, aby se reviewer mohl kouknout na jeden diff misto padesati. Pokud je to obzvlast velka nebo komplikovana zmena, tak je tam tech commitu vic, ale je to spis vyjimka. Konkretne k tem otazkam teda plati, ze spoustu malych ale ucelenych commitu delame lokalne. Pro PR a souvisejici review se to ale squashne do jednoho commitu na kazdy work item, aby se snaz cetla historie sdilenych dlouho zijicich branchi (develop, master) a dobre se to integrovalo s Jirou (pres ticket ID v nazvu branche, nemusi pak byt v kazde messagi). Jsou z toho vyjimky, ale u nich je to tak, ze jde treba o vetsi refactoring, ktery nema vlastni work item. Pak se mi spis hodi mit oddelene commity na reafactoring a samotnou implementaci tasku pro snadnejsi orientaci v historii a jednodussi diffy, ale vetsina refactoringu se v klidu vejde i do toho jednoho commitu.

(OT: Ted jsme Bitbucket updatovali na verzi, ktera uz umi squash automaticky jako merge strategy pro PR, takze by nemel byt problem udelat PR s jednotlivymi local commity a squashnout to po review, ale to teprve musime vyzkouset. Podle me stejne budeme delat aspon castecny squash pred PR, aby to byly nejake ucele bloky zmen nebo jeden commit jako doted)

Na druhem projektu je SVN bez dalsich nastroju (krome lokalnich jako Tortoise, Ankh), kde feature branche a mergovani jsou docela zlo, takze se vetsinou dela lokalne bez prubeznych commitu a pak se pred commitem dela code review osobne, pripadne se udela patch file. Tenhle proces je o poznani horsi, protoze chybi prubezne verzovani a krome dalsich zjevnych nevyhod se pak ani neda vybrat, jestli udelat jeden velky commit a nebo vetsi mnozstvi mensich. Resp. samozrejme jde commitovat prubezne, ale chce to mit opravdu dobrou disciplinu, kvalitni CI, ale i pak se spatne seskupuji commity na jedno review, protoze mezi nimi muze delat zmeny nekdo dalsi. Feature branche toho bohuzel na SVN moc neresi.

Ani v jednom pripade nenutime git push/SVN commit na konci pracovni doby, i kdyz mozna by to prospelo nauceni lepsiho cleneni tasku s ohledem na CI.

Komentáře

  • kluvi : My například v Bitbucketu vůbec neřešíme commity. Všechno jen na úrovní PR, commity nechváme na zodpovědnosti vývojáře. Obsah commitů se totiž blbě vynucuje (různé "temp commit" při přepínání mezi větvema s rozdělanou prací,...), zatímco u PR si můžu nastavit pravidla co a jak. Když se pak řeší nějaký problém, tak se stejně začíná obvykle hledat z Jiry, kde si najdeme konkrétní issue a u té si pak proklikám související PR. Dřív jsme používali SVN, takže teď je to prakticky tak, že počet commitů v SVN = počet PR => rapidně vzrostl počet commitů. Já osobně commituju zvlášť opravdu každou blbost a snažím se to co nejvíc funkčně oddělovat. Někteří kolegové na to ale pečou a commitují občas nefunkční marast. Ve výsledku je to ale stejně jedno, protože diff toho PR je pořád stejný. OT: nevím, jestli jste si toho všimli, ale v nové verzi Bitbucketu umí vyhledávat už i přímo v kódu (klasicky přes to vyhledávací pole nahoře). Po upragdu jsme ale museli ručně nahodit Elasticsearch, který je tam přibalený. Pokud ale používáte hostovnou verzi, tak tam nevím jak to je - my to máme u nás na serveru. 25.10.2016
  • vosykapavel : O možnosti squashování commitů jsem vůbec nevěděl. Dík za odpověď :-) 31.10.2016
  • Honza Břešťan : Nekdo squashovani nemusi, ale nasemu flow vyhovuje - urcite stoji za zvazeni. Vyzkousel jsem to automaticke squashovani PR v Bitbucketu, ale nejde to udelat tak, aby zaroven provedl squash a zaroven ten finalni commit do target branche byl oznaceny jako merge commit. V grafu historie pak zustane ta feature branch viset a vsechny commity jsou primo na developu - nikde neni naznak, kde se vzaly. Pro nekoho to nemusi byt problem (kdyz se feature branch smaze, tak zustane jedna krasne linearni historie), ale mne prijde, ze se tim ztraci kus informace, takze budem nejspis dal delat squashe rucne a PR mergovat merge commitem bez FF. 31.10.2016

Pro zobrazení všech 10 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.