ReviewCode, verzování, commity,... rubrika: Nástroje: Verzování
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:
- 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.
- 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.
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.
Pro zobrazení všech 10 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře