E o metrica nu foarte relevanta (cam ca asta: https://en.wikipedia.org/wiki/Source_lines_of_code ) dar e mai mult decat nimic.
La mine in afara de cod au mai fost si o serie de teste, care nu se reflecta in commit nicicum.
Chiar si cand lucrez singur pe repo, incerc sa fac commit-uri suficient de scurte incat sa nu puna probleme in cazul unui code review.
De asemenea, incerc sa nu introduc 2 unit-of-work in acelasi commit (in lipsa unui termen mai bun).
Daca am de facut un refactor mic inaintea implementarii functionalitatii principale, va fi un commit separat.
Whitespace police: commit separat.
s.a.m.d.
Am folosit unit-of-work in sensul de a nu amesteca adaugarea unui camp in baza de date cu modificarea unei metode de calcul in alt modul al aplicatiei si adaugarea unor linii de log suplimentare in alta parte, totul intr-un singur commit (chiar daca sunt 10 linii de cod modificate in total).
Chiar si in cazul unei singure modificari logice, incerc sa adaug mai multe commit-uri care sa evidentieze etapele implementarii. Sper sa gasesc un PR pe github care sa exemplifice frumos ce incerc sa spun.
Inteleg ce zici tu, dar aici era o singura clasa modificata, o anumita functionalitate doar. Nu putea fi separata in bucati mai mici. Bucata asta era functionala doar cu toata modificarea din commit.
Pai la asa ceva, asa trebuie facut commit. E o mare diferenta intre proiectele care au zero issues (cazul meu pentru proiectul initial), care sunt in faza de constructie - inceput de doua luni - si asa ceva. Proiectul ala e antic (din 2011?), lucreaza multi la el, nu se pot face comparatii de genul asta.
Şi eu prefer să fac commit-uri foarte detaliate. La un moment dat mi-a fost de mare ajutor abordarea astea, când am avut nevoie să fac release la o versiune mai veche, cu doar câteva cherry-pick-uri din commit-urile ulterioare. Dacă ar fi fost commit-uri “monolit”, aş fi avut mari dureri de cap
Fiecare cu ale lui. Depinde de proiect, de stilul de lucru.
Mie îmi place cu multe commit-uri mici, dar pe un branch. Commit-urile incerc sa le tin focused si atomice cumva - înainte de modificări proiectul este într-o stare buna, după modificări tot într-o stare bună. Evit commit-uri când proiectul nu compilează, nu trec teste etc. Ajuta mult la refactor-uri mari sa o iei pe bucăți
Eu fac commit-uri când iau pauze, adică la 1-2 ore
Prefer să fac commit după mici progrese.
Dacă este un component mare îl țin detașat de restul aplicației până în ultima clipă.
De obicei incerc sa fac modificari doar legate de o anumita functionalitate sau fix si atunci commit-ul e destul de mic.
Cand lucrez la o functionalitate sau fix mai mare (care se va termina cu un PR), atunci imi fac treaba, dupa care utilizez GitHub Desktop unde pot sa vizualizez mai usor ce am modificat si sa grupez acele modificari in mai multe commit-uri (poti sa selectezi ce fisiere sa incluzi sau chiar sa mergi mai detaliat si sa alegi ce linii din fisier sa includa).
Asta ar putea sa functioneze in cazul OP-ului, unde lucrezi o zi intreaga la ceva si in loc sa faci un singur commit, mergi prin modificari si le grupezi frumos in mai multe commit-uri.