Pull Request: ce este, procesul de creare și code review

Ce este Pull Request?

Pull Request (PR) — este o cerere formală de includere a modificărilor dintr-o ramură în alta în cadrul unui sistem distribuit de control al versiunilor. PR este elementul central al dezvoltării colaborative pe platformele GitHub, GitLab și Bitbucket, combinând discuția codului, testarea automată și procesul de aprobare a modificărilor.

Denumirea „Pull Request” reflectă esența operațiunii: dezvoltatorul cere (request) proprietarului depozitului să „prelueze” (pull) modificările sale. Termenul a fost introdus de GitHub în 2008 — înainte de aceasta, un mecanism similar exista sub formă de patch-uri și merge request (termen GitLab). Astăzi, PR este standardul de facto pentru lucrul în echipă cu Git.

Potrivit GitHub Octoverse, 2025, 89% dintre proiectele open-source necesită crearea unui PR pentru a face modificări. În dezvoltarea corporativă, acest indicator atinge 95%. PR a devenit nu doar un instrument tehnic, ci o parte a culturii de dezvoltare: prin PR are loc transferul de cunoștințe, detectarea bug-urilor și coordonarea deciziilor arhitecturale.

Componentele Pull Request

Un PR tipic constă dintr-un titlu, descriere, lista fișierelor modificate (diff), comentariile reviewerilor și statusurile verificărilor CI. Fiecare PR este legat de o ramură sursă și o ramură țintă specifice, iar după fuzionare poate fi șters automat.

Cum să creați Pull Request

Crearea PR începe cu publicarea ramurii feature în depozitul la distanță. După push, dezvoltatorul deschide PR prin interfața platformei sau prin CLI (gh, glab). Să analizăm procesul pe exemplul GitHub.

Push-ul ramurii și deschiderea PR

Primul pas — să trimiteți ramura feature în depozitul la distanță și să creați Pull Request prin interfața web sau linia de comandă.

# Creați și trimiteți ramura feature
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Creați PR prin GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

După crearea PR, GitHub lansează automat pipeline-urile CI (GitHub Actions), verifică existența conflictelor cu ramura țintă și invită reviewerii. Șablonul de descriere a PR poate fi configurat prin .github/PULL_REQUEST_TEMPLATE.md pentru ca toate PR-urile să conțină secțiuni obligatorii: scop, modificări, testare, sarcini conexe.

Descrierea și etichetarea

O descriere de calitate a PR include: link către sarcină (issue/ticket), o scurtă descriere a modificărilor, instrucțiuni de testare și lista modificărilor conexe. Etichetele (bug, feature, refactoring) ajută la categorisirea PR-urilor, iar assignees și reviewers sunt atribuiți automat prin CODEOWNERS.

# Atribuiți reviewerii prin CODEOWNERS (fișierul din directorul rădăcină al depozitului)
# Exemplu .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Creați PR cu atribuirea reviewerilor prin gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — un mecanism standard GitHub/GitLab pentru atribuirea automată a reviewerilor în funcție de fișierele modificate. De exemplu, orice modificare în directorul src/auth/ atribuie automat ca revieweri pe team-auth și senior-dev. Aceasta accelerează procesul și garantează că persoanele potrivite vor vedea PR-ul.

Actualizarea PR după review

După primirea comentariilor reviewerului, dezvoltatorul face corecții în aceeași ramură feature și trimite commit-uri noi — PR se actualizează automat. Este important să nu rescrieți istoricul (rebase) în ramura feature publicată dacă PR este deja deschis, deoarece aceasta strică linkurile către commit-urile specifice din comentarii.

# Faceți modificări conform comentariilor reviewerului
git checkout feature/biometric-auth
# corectați codul
git commit -m "fix: handle biometric timeout per review"
git push

# PR se va actualiza automat
# După aprobare — fuzionați PR prin interfața GitHub

Procesul de code review

Code review — elementul central al Pull Request. Reviewerul verifică modificările pentru corectitudine, stil de cod, securitate și coerență arhitecturală. Un review de calitate nu doar previne bug-urile, ci și răspândește cunoștințele despre baza de cod în cadrul echipei.

Engineering Practices Google (2025) recomandă următoarele principii de code review: reviewerul trebuie să înțeleagă contextul modificărilor, să ofere recomandări concrete în loc de observații generale, să separe comentariile tehnice de cele stilistice. Timpul de review nu trebuie să depășească 24 de ore de la crearea PR.

Pentru dezvoltarea de aplicații mobile, code review include verificări specifice: compatibilitatea cu targetSdk, corectitudinea gestionării lifecycle (Android) / view lifecycle (iOS), absența scurgerilor de memorie (LeakCanary, Instruments), suport pentru tema întunecată și localizare. Aceste verificări pot fi automatizate prin lintere și Detekt/ktlint.

Tipuri de comentarii

Platformele PR suportă trei tipuri de comentarii: generale (la întregul PR), pe linie (la o linie specifică de cod) și sugestii (suggestions cu cod de înlocuire). Sugestiile permit aplicarea modificării cu un singur clic, ceea ce accelerează procesul și reduce numărul de iterații.

După ce toate comentariile sunt rezolvate și verificările CI sunt trecute, reviewerul trimite aprobarea (Approved). PR poate fi fuzionat. GitHub și GitLab suportă reguli de protecție a ramurilor (branch protection rules): numărul obligatoriu de aprobări, verificări CI obligatorii, interdicția de a face push în main fără PR. Pentru proiectele mobile, branch protection include și verificarea build-ului: PR nu poate fi fuzionat dacă aplicația nu se compilează (gradle build failed / xcodebuild failed).

Rezolvarea conflictelor în PR

Conflictele de merge în Pull Request sunt o situație normală în munca activă de echipă. Platformele oferă rezolvarea conflictelor prin interfața web (pentru conflicte simple) sau recomandă rezolvarea locală. GitHub Actions verifică automat posibilitatea de fuzionare la fiecare push în ramura feature și marchează PR ca conflict dacă fuzionarea nu este posibilă.

Cele mai bune practici Pull Request

Pull Request-urile eficiente accelerează code review și reduc numărul de bug-uri. Cercetarea SmartBear (2025) a arătat că PR-urile de până la 200 de linii de cod primesc de 2 ori mai multe comentarii substanțiale decât PR-urile cu peste 1000 de linii, iar timpul de review se reduce de 3 ori.

• PR-uri mici — dimensiunea optimă 100-300 de linii. Împărțiți PR-urile mari în părți logice: fiecare PR rezolvă o singură sarcină. Aceasta simplifică review-ul și reduce probabilitatea conflictelor
• Descriere clară — titlu conform Conventional Commits (feat:, fix:, refactor:), conținutul PR include „ce și de ce”, nu „cum” (codul vorbește de la sine). Șablon: scop → modificări → testare → probleme conexe
• Feedback rapid — review în termen de 24 de ore. Dacă PR așteaptă mai mult de o zi — echipa pierde contextul, crește numărul de conflicte la merge
• Automatizare — lintere, formattere și teste trebuie să se lanseze automat la crearea PR. Nu permiteți fuzionarea PR-urilor cu verificări CI roșii
• Draft PR — utilizați pentru discuții timpurii despre arhitectură. Draft PR nu necesită review și nu poate fi fuzionat, dar permite să arătați codul colegilor într-un stadiu incipient

Practici suplimentare: nu creați PR vineri seara (nimeni nu va face review până luni), solicitați review de la 1-2 persoane (mai multe încetinesc procesul fără a crește calitatea), utilizați squash merge pentru comprimarea istoricului înainte de fuzionare. Pentru proiecte mobile, se recomandă și adăugarea în descrierea PR a unui link către build-ul de test (Firebase App Distribution / TestFlight) pentru ca reviewerul să poată verifica modificările în aplicația funcțională.

Pull Request pe diferite platforme

Principalele platforme pentru lucrul cu Pull Request — GitHub, GitLab și Bitbucket. În ciuda conceptului comun, fiecare are caracteristici care trebuie luate în considerare la alegerea instrumentului pentru echipă.

GitHub — cea mai populară platformă cu cea mai mare comunitate, Actions pentru CI/CD și un ecosistem vast de aplicații (GitHub Marketplace). GitLab se remarcă prin CI/CD integrat și posibilitatea de implementare completă self-hosted. Bitbucket este strâns integrat cu Jira și ecosistemul Atlassian, popular în mediul corporativ.

Pentru dezvoltarea de aplicații mobile, alegerea platformei este adesea determinată de capacitățile CI/CD: GitHub Actions suportă ruloare macOS pentru compilarea iOS, GitLab are ruloare integrate pentru iOS/Android, Bitbucket se integrează bine cu Firebase Test Lab. Independent de platformă, procesul PR rămâne același: ramură → review → CI → merge.