Cum faci un Pull/Merge Request?

Cum faci un Pull/Merge Request?

Dacă folosești Bitbucket sau Github îi zice Pull Request, iar dacă folosești GitLab îi zice Merge Request, dar practic sunt denumiri diferite ale aceleiași funcționalități: permite o colaborare eficientă între doi sau mai mulți oameni.

Ca să aibă succes, trebuiesc urmate câteva reguli simple. Atât de simple încât sunt cu succes ignorate și iese un mic haos.

Care sunt regulile?

  1. Cauți și citești Submission Guidelines în proiectul la care vrei să contribui.
  2. Faci fork la proiect și îl clonezi local.
  3. Iei aminte care este branch-ul principal (în mod frecvent, acesta este master) și faci un branch nou, de preferat cu un nume sugestiv: git checkout -b patch-1 s-ar putea să fie prea generic; git checkout -b oauth-with-facebook sună mai bine, nu?
  4. Faci commit-uri dese. Cât de dese? Depinde de tine, dar încearcă să nu ai mai mult de 10-20 linii de cod/commit, iar asta din două motive: schimbările vor fi mai ușor de urmărit și reduci riscul de conflicte.
  5. Faci modificări în cod ce țin strict de acel feature. Da, poate crezi că o metodă ar merge rescrisă ceva mai bine, dar pentru asta faci un alt pull request. Exceptând cazul în care modificarea reprezintă ceva minor (e.g. un typo, un indent greșit), faci PR!
    • sub nici o formă nu te apuci să faci merge de pe alte branch-uri în branch-ul în care lucrezi. Înseamnă ori conflicte, ori un PR respins.
    • Urmărești stilul de cod de la codul existent. Dacă indentarea se face cu tab-uri, nu încerci să-i educi să folosească spații (sau invers; asta e o treabă ce ține de un alt PR!), fii atent la spațiere (între paranteze, după/înainte paranteze, unde sunt plasate acoladele șamd)
  6. În cazul în care faci mai multe PR-uri, pe toate le pornești din branch-ul principal (cel de la punctul 3)! Da, e tentant să pornești un feature dintr-un alt feature (e.g. din oauth-with-facebook să pornești refactor-user-management), dar nu o face, altfel ai toate șansele să ți se respingă PR-ul.

Cam atât.

Partea curioasă este că pașii 4+ nu sunt menționați prea des nicăieri, prin urmare apar PR-uri ciudate, greu de urmărit și, evident, sunt respinse, generând frustrări în rândul colaboratorilor.

6 Comentarii

paul a scris

10-20 linii per commit e doar un guideline. in realitate, un commit ar trebui sa reprezinte o singura modificare de sine statatoare.

Cat despre felul in care se intampla povestea, depinde de coding standard. De exemplu, am vazut proiecte care te puneau sa faci rebase inainte astfel incat istoricul sa fie cat mai simplu. Cand ai un istoric de 20000 de commituri in care jumate sunt schimbat o litera, adaugat un spatiu, nu ajuta pe nimeni. Sau ajuta. Depinde de policy.

La fel si cu coding standard. Un proiect serios are prin documentatie un fisierut in care zice unde se pune acolada, cu ce si cat se identeaza, etc. Si langa el, un altul in care explica tot policy-ul de pull request. Si nu dureaza mai mult de 10 minute sa le citesti.

Ionuț Staicu a scris

inainte astfel incat istoricul sa fie cat mai simplu

Păi nu pentru asta există squash? :)

Nu știu Gitlab, dar Github știe sigur să facă un singur commit, indiferent câte commit-uri sunt într-un PR.

nu ajuta pe nimeni

De fapt ajută: mai multe commit-uri înseamnă mai puține șanse de a avea un conflict la merge, mai ales dacă PR-ul schimbă mult cod, explicația fiind că există diff-uri mai detaliate și git își poate da seama mai ușor care bucată a apărut prima în cazul în care două commit-uri (cu doi autori adică) modifică același fișier în (aprox) același loc. Am citit asta undeva dar nu mai găsesc unde, revin dacă îmi amintesc.

paul a scris

@Ionuț Staicu: squash face rebase in backend.

Sunt de acord cu ce zici despre merge, dar eu ma refeream ca, din punct de vedere al istoricului proiectului, daca tii toate commiturile devine greu de citit/cautat prin istoric, asa ca unele proiecte prefera un istoric mai curat. Cat despre problema merge-urilor, care sunt intr-adevar facilitate de commituri mici, se poate face rebase/squash si dupa merge.

Mai mult, exista situatii in care se face deploy prin git (e.g. puppet). Poti avea niste commit hooks care verifica sintaxa, dar mai mult decat atat, trebuie sa dai un push pentru a putea testa codul. Asa ca pe feature branches ai o gramada de commituri de genul „fixed typo”. Inutile pentru long-term history.

Ionuț Staicu a scris

@paul: că sunt sau nu ținute toate commit-urile nu mai e problema celui ce trimite PR-ul.

Mai este un alt avantaj al commit-urilor dese: cel care face review poate urmări mai ușor ce se întâmplă în cod.

Dar am menționat că typo-urile sunt ceva minor ce pot intra grămadă pe un PR (și pe un commit) :)

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter