Cum arata la voi un commit pe git dupa o zi de lucru?

La mine pentru astazi e asa:

 4 files changed, 632 insertions(+), 173 deletions(-)

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.

E doar o curiozitate…

1 Like

Un commit pe zi? :confused:

Poți detalia?

In 99% din cazuri e o greseala :smile:

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.

Deseori fac unul singur. Depinde de ce anume adaug/modific. Daca sunt chestii independente, fac mai multe commit-uri.

Cat despre teste, pur si simplu am niste device-uri IoT cu care verific functionalitatea. Nu intotdeauna implica scrierea de cod suplimentar.

Eu practic lucrez singur pe repo. Exista exceptii, dar sunt minuscule si rare.

Unit-of-work in cazul de mai sus chiar a fost pentru intreaga zi. Nu putea fi spart in bucati mai mici, independente.

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.

Uite aici un exemplu: https://github.com/aromanro/DFTAtom/commit/96326ef8adae963f0cb37252785de3c3c095b8d3

Showing 1 changed file with 6 additions and 6 deletions . :smiley:

How about this? https://github.com/psf/requests/pull/1776/commits

1 Like

Fix 1728 (Fixed up from #1729) #1776

210 Open 2763 Closed.

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.

Trebuie sa iti intre in obisnuinta stilul asta.

Si eu sunt lenes :smile: dar incerc sa fac lucrurile asa cum trebuie chiar si pe scripturi de cateva sute de linii de python.

Vrei sa zici ca ai un zillion de commit-uri la scripturi de cateva sute de linii? Not good :slight_smile:

Chill :smiley:

Fiecare proiect cu stilul lui, git commits are cheap.

1 Like

Pai incepe sa semene cu Biblia daca bagi commit-uri la greu: mai multe modificari decat numarul de cuvinte folosit :slight_smile:

Ş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 :slight_smile:

La mine ar fi munca pe ultimele doua zile intr-un PR, refactoring + new features:

Files changed 42, 1,071 insertions(+), 1,604 deletions(-)

Inainte de asta new features + refactoring (1 zi de lucru):

Files changed 23, 488 insertions(+), 270 deletions(-)

Sunt variatii mari in timp in functie de tipul de task (new feature, bugfix, …).

Incerc sa nu lucrez mai mult de 1-3 zile pe un feature branch dar nu-mi iese totdeauna.

1 Like

Cam asa procedez si eu de suficient de multe ori: https://github.com/torvalds/linux/pull/671/commits

  • scriu ceva cod (primul commit)
  • dupa care gasesc un alt motiv de a-l modifica (commit separat)
  • mai uit ceva whitespace pe la colturi (alt commit).

si lista poate sa continue.

Evident, la un moment dat, cand nu mai apar buguri noi in zona respectiva si sunt suficient de increzator, mai fac cate un squash.

1 Like

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

1 Like

Eu fac commit-uri când iau pauze, adică la 1-2 ore :slight_smile:
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.

That’s my 2 cents.