A aproba / A da approval: ce este, approval și code review în Git

Ce este aprobarea pull request

Aprobarea (approval) — este o recenzie pozitivă asupra pull request, însemnând că recenzentul a verificat codul, nu a găsit probleme critice și consideră modificările gata pentru fuziune. În interfața GitHub, acesta este butonul verde «Approve» pe pagina PR. După aprobare, autorul (sau orice participant cu drepturi de scriere) poate efectua merge.

Procesul de aprobare face parte din Branch Protection Rules. Proprietarii depozitului configurează cerințele obligatorii: numărul minim de aprobări (de exemplu, 1 sau 2), cine poate aproba (proprietarii de cod, membrii echipei) și dacă PR trebuie să fie re-aprobat după modificări (Dismiss stale reviews). Fără configurarea regulilor, aprobarea este un pas opțional, dar în echipele profesionale este obligatorie.

GitLab folosește un mecanism similar numit Approval Rules. În GitLab, poți configura de câte aprobări este nevoie de la diferite grupuri (de exemplu, 2 de la dezvoltatorii backend și 1 de la DevOps). După primirea tuturor aprobărilor obligatorii, PR este deblocat automat pentru merge cu condiția unui CI/CD pipeline verde.

Tipuri de revizuire: Approve, Request Changes, Comment

În GitHub și GitLab există trei tipuri de revizuire pe care recenzentul le poate lăsa pe un pull request. Fiecare tip are un statut diferit și consecințe pentru procesul de fuziune. Approve — verde, Request Changes — roșu, Comment — gri neutru. Alegerea tipului depinde de calitatea codului și de pregătirea modificărilor pentru acceptare.

Approve — recenzentul confirmă: codul este scris corect, respectă standardele, nu conține erori evidente și poate fi fuzionat. Approve nu înseamnă că codul este ideal — doar că este suficient de bun pentru producție. Dacă există observații minore (stil, denumiri), acestea pot fi lăsate ca comentarii fără a bloca PR.

Request Changes — recenzentul găsește probleme care trebuie rezolvate înainte de merge: erori logice, vulnerabilități, încălcări ale arhitecturii, lipsa testelor. După Request Changes, PR este blocat, iar pentru deblocare este necesară o nouă aprobare de la același recenzent (dacă opțiunea Dismiss stale reviews este activată pentru commiturile noi).

• Approve — codul este gata de fuziune, se poate face merge după trecerea CI.
• Request Changes — corecturi obligatorii, PR blocat până la o nouă revizuire.
• Comment — observație generală sau sugestie fără blocarea PR.

Configurarea regulilor de aprobare în depozit

Branch Protection Rules — este mecanismul GitHub pentru controlul calității fuziunilor. Se configurează în Settings → Branches pentru fiecare ramură protejată (main, develop, release/*). Parametrii principali: numărul de aprobări obligatorii, proprietarii de cod (CODEOWNERS), verificarea obligatorie CI/CD și interzicerea push fără PR.

Parametrul Dismiss stale pull request approvals — elimină automat aprobările dacă un commit nou este adăugat în PR. Acest lucru garantează că recenzenții aprobă exact versiunea de cod care va fi fuzionată. Fără această setare, autorul poate adăuga cod nou după aprobare, iar acesta va ajunge în main fără o nouă verificare.

CODEOWNERS — un fișier în rădăcina depozitului care desemnează responsabili pentru diferite directoare. Dacă PR afectează fișierele aparținând unui proprietar de cod, aprobarea acestuia devine obligatorie. CODEOWNERS permite distribuirea zonelor de responsabilitate: dezvoltatorul iOS răspunde de fișierele Swift, DevOps — de configurațiile Docker, testerii — de scenariile de testare.

# Exemplu de fișier CODEOWNERS în rădăcina depozitului

# Dezvoltatorii iOS dețin codul Swift
*.swift @team/ios-developers

# DevOps deține configurația CI/CD
.github/workflows/* @devops-team

# Inginerii QA revizuiesc testele
**/tests/* @qa-engineers

# Proprietari impliciți pentru orice altceva
* @tech-leads

Code review înainte de aprobare: ce să verifici

Code review înainte de aprobare — este o verificare sistematică a codului, nu o privire superficială peste diff. Un code review de calitate include verificarea arhitecturii, logicii, stilului, testelor și securității. Fără această verificare, aprobarea devine o formalitate, nu un instrument de control al calității.

Ce se verifică în primul rând: logica modificărilor — codul rezolvă problema stabilită, există efecte secundare, gestionarea cazurilor limită este corectă. Testele — noile teste acoperă toate scenariile, testele existente trec după modificări. Securitatea — există injecții SQL, XSS, scurgeri de date sensibile.

Ce nu ar trebui să fie obiectul revizuirii: stilul de formatare (pentru asta există lintere și formattere), deciziile arhitecturale luate în prealabil (se discută înainte de scrierea codului). Dacă revizuirea are mai mult de 400 de linii sau durează mai mult de o oră — acesta este un semnal că sarcina este prea mare și necesită descompunere. Cele mai bune practici de revizuire — porții de 200–400 de linii în termen de 24 de ore de la crearea PR.

• Logica — corectitudinea rezolvării sarcinii, gestionarea erorilor, cazurile limită.
• Testele — acoperirea noilor scenarii, trecerea celor existente, absența testelor instabile.
• Securitatea — absența injecțiilor, ecranarea ieșirii, accesul la date.
• Performanța — eficiența algoritmilor, interogări redundante, scurgeri de memorie.
• Documentația — documentația este actualizată, comentariile din secțiunile complexe sunt ușor de înțeles.

Fluxul de lucru cu aprobare în echipă

Un flux de lucru tipic cu aprobare într-o echipă de 5–10 dezvoltatori arată astfel: dezvoltatorul creează PR, desemnează recenzenți (de obicei 1–2 persoane din echipă sau proprietari de cod), CI/CD lansează verificări automate. După primirea tuturor aprobărilor obligatorii și a CI verde, autorul efectuează merge. Timpul de la crearea PR până la merge este în medie de la 2 ore la 2 zile, în funcție de complexitate.

GitHub Actions permit automatizarea merge după aprobare. Dacă regulile ramurilor sunt configurate, GitHub blochează singur merge până la îndeplinirea tuturor condițiilor. Unele echipe folosesc bors-ng sau Mergify — boți care fuzionează automat PR după primirea tuturor aprobărilor și trecerea CI. Acest lucru accelerează procesul și elimină factorul uman la merge.

Abordarea modernă — trunk-based development cu ramuri de scurtă durată. În acest flux de lucru, aprobarea trebuie obținută în câteva ore, altfel sarcina este considerată depășită și necesită resincronizare cu main. Echipele cu o cultură înaltă de revizuire tind să aibă un timp de aprobare de cel mult 4 ore lucrătoare.

Erori la aprobare și cum să le eviți

Cea mai frecventă eroare — aprobarea formală fără o verificare reală a codului. Când PR este mare sau termenul limită este aproape, recenzentul poate apăsa Approbe fără a intra în detalii. Acest lucru devalorizează întregul proces de code review. Soluție: stabiliți o limită pentru dimensiunea PR (nu mai mult de 400 de linii) și folosiți instrumente de analiză a codului (SonarQube, CodeClimate) pentru verificare automată.

A doua eroare — aprobare excesiv de strictă. Așteptarea unui cod ideal blochează dezvoltarea. Recenzenții cer uneori să fie corectate observații stilistice care nu afectează calitatea. Soluție: separați clar observațiile obligatorii (blocante) de sugestiile opționale (comentarii). GitHub permite să indicați explicit dacă un comentariu este blocant.

A treia eroare — aprobarea fără verificarea CI/CD. Chiar dacă codul arată corect, s-ar putea să nu se compileze sau să pice la teste. Branch Protection configurat blochează automat merge la CI roșu, dar unele echipe dezactivează această protecție pentru viteză. Soluție: verificați întotdeauna starea CI înainte de aprobare și nu aprobați niciodată un PR cu pipeline roșu.

• Aprobarea formală — lipsa verificării reale a codului. Soluție: limită de 400 de linii per PR.
• Strictețe excesivă — blocarea din cauza observațiilor stilistice. Soluție: împărțire în blocking și optional.
• Ignorarea CI — aprobarea la pipeline roșu. Soluție: verificați întotdeauna starea verificărilor.
• Desemnarea autorului — aprobarea de la autorul PR. Soluție: configurarea Branch Protection împotriva autorului.