Jóváhagyni / Approválni: mi ez, approval és code review a Gitben

Mi az a pull request jóváhagyás

Jóváhagyás (approval) — pozitív review a pull requesten, ami azt jelenti, hogy a reviewr ellenőrizte a kódot, nem talált kritikus problémákat, és a változtatásokat egyesítésre késznek tartja. A GitHub felületen ez a zöld «Approve» gomb a PR oldalán. Jóváhagyás után a szerző (vagy bármely írási joggal rendelkező résztvevő) elvégezheti a merge-t.

A jóváhagyási folyamat a Branch Protection Rules része. A repozitórium tulajdonosai beállítják a kötelező követelményeket: minimális jóváhagyási szám (pl. 1 vagy 2), ki jóváhagyhat (kódtulajdonosok, csapattagok), és hogy a PR-t újra kell-e jóváhagyni változtatások után (Dismiss stale reviews). A szabályok beállítása nélkül a jóváhagyás opcionális lépés, de a professzionális csapatokban kötelező.

A GitLab hasonló mechanizmust használ Approval Rules néven. A GitLabban beállítható, hogy hány jóváhagyás szükséges különböző csoportoktól (pl. 2 a backend fejlesztőktől és 1 a DevOps-tól). Az összes kötelező jóváhagyás megérkezése után a PR automatikusan feloldódik a merge számára a zöld CI/CD pipeline feltételével.

Review típusok: Approve, Request Changes, Comment

A GitHubban és GitLabban háromféle review létezik, amelyet a reviewr hagyhat egy pull requesten. Minden típusnak más az állapota és következménye az egyesítési folyamatra. Approve — zöld, Request Changes — piros, Comment — semleges szürke. A típus kiválasztása a kód minőségétől és a változtatások elfogadási készségétől függ.

Approve — a reviewr megerősíti: a kód helyesen van megírva, megfelel a szabványoknak, nem tartalmaz nyilvánvaló hibákat, és egyesíthető. Az Approve nem azt jelenti, hogy a kód ideális — csak hogy elég jó a élesüzemhez. Ha apró észrevételek vannak (stílus, elnevezések), ezek megjegyzésként hagyhatók a PR blokkolása nélkül.

Request Changes — a reviewr olyan problémákat talál, amelyeket a merge előtt meg kell javítani: logikai hibák, sebezhetőségek, architektúrális megsértések, tesztek hiánya. A Request Changes után a PR blokkolva van, és a feloldáshoz ugyanazon reviewr újabb jóváhagyása szükséges (ha a Dismiss stale reviews opció be van kapcsolva új commitok esetén).

• Approve — a kód kész az egyesítésre, merge lehetséges a CI átmenete után.
• Request Changes — kötelező javítások, a PR blokkolva az újra review-ig.
• Comment — általános észrevétel vagy javaslat a PR blokkolása nélkül.

Jóváhagyási szabályok beállítása a repozitóriumban

Branch Protection Rules — a GitHub mechanizmusa az egyesítések minőségellenőrzéséhez. A Settings → Branches menüben állítható be minden védett ághoz (main, develop, release/*). Fő paraméterek: kötelező jóváhagyások száma, kódtulajdonosok (CODEOWNERS), kötelező CI/CD ellenőrzés és a push tiltása PR nélkül.

A Dismiss stale pull request approvals paraméter — automatikusan eltávolítja a jóváhagyásokat, ha új commit kerül a PR-be. Ez garantálja, hogy a reviewrok pontosan azt a kódverziót hagyják jóvá, amely egyesítésre kerül. E beállítás nélkül a szerző új kódot adhat hozzá a jóváhagyás után, és az újraellenőrzés nélkül kerül a main-be.

CODEOWNERS — egy fájl a repozitórium gyökerében, amely felelősöket jelöl ki a különböző címtárakhoz. Ha a PR a kódtulajdonos fájljait érinti, az ő jóváhagyása kötelezővé válik. A CODEOWNERS felelősségi területeket oszt fel: az iOS fejlesztő felel a Swift fájlokért, a DevOps — a Docker konfigurációkért, a tesztelők — a teszt forgatókönyveért.

# Példa CODEOWNERS fájl a repo gyökerében

# Az iOS fejlesztők birtokolják a Swift kódot
*.swift @team/ios-developers

# A DevOps birtokolja a CI/CD konfigurációt
.github/workflows/* @devops-team

# A QA mérnökök áttekintik a teszteket
**/tests/* @qa-engineers

# Alapértelmezett tulajdonosok minden máshoz
* @tech-leads

Code review jóváhagyás előtt: mit ellenőrizzünk

Code review a jóváhagyás előtt — a kód szisztematikus ellenőrzése, nem a diff felüzetes áttekintése. A minőségi code review magában foglalja az architektúra, logika, stílus, tesztek és biztonság ellenőrzését. Ezen ellenőrzés nélkül a jóváhagyás formalitássá válik, nem pedig minőségellenőrző eszközzé.

Mit ellenőrzünk elsőként: a változtatások logikáját — a kód megoldja-e a feladatot, vannak-e mellékhatások, helyes-e a határesetek kezelése. Teszteket — az új tesztek lefedik-e az összes forgatókönyvet, átmennek-e a meglévő tesztek a változtatások után. Biztonságot — vannak-e SQL injekciók, XSS, érzékeny adatok szivárgása.

Mi nem lehet review tárgya: formázási stílus (ehhez linterek és formatterek vannak), előre meghozott architektúrális döntések (ezeket a kód írása előtt beszélik meg). Ha a review több mint 400 sor, vagy több mint egy óráig tart — ez annak a jele, hogy a feladat túl nagy és dekompozíciót igényel. A review legjobb gyakorlata — 200–400 soros részek a PR létrehozásától számított 24 órán belül.

• Logika — a feladat megoldásának helyessége, hibakezelés, határesetek.
• Tesztek — új forgatókönyvek lefedettsége, meglévők átmenete, flaky tesztek hiánya.
• Biztonság — injekciók hiánya, kimenet escape-elése, adatokhoz való hozzáférés.
• Teljesítmény — algoritmusok hatékonysága, többlet lekérdezések, memóriaszivárgás.
• Dokumentáció — frissítve van-e a dokumentáció, érthetők-e a megjegyzések az összetett részekben.

Munkafolyamat jóváhagyással a csapatban

Egy tipikus 5–10 fejlesztőből álló csapatban a jóváhagyással rendelkező munkafolyamat így néz ki: a fejlesztő létrehozza a PR-t, kijelöli a reviewrokat (általában 1–2 fő a csapatból vagy kódtulajdonosokat), a CI/CD elindítja az automatikus ellenőrzéseket. Az összes kötelező jóváhagyás és a zöld CI megérkezése után a szerző elvégzi a merge-t. A PR létrehozásától a merge-ig eltelt idő átlagosan 2 órától 2 napig terjed a összetettségtől függően.

A GitHub Actions lehetővé teszi a merge automatizálását a jóváhagyás után. Ha az ágszabályok be vannak állítva, a GitHub maga blokkolja a merge-t az összes feltétel teljesüléséig. Néhány csapat bors-ng vagy Mergify — olyan botokat használ, amelyek automatikusan egyesítik a PR-t az összes jóváhagyás és a CI átmenete után. Ez felgyorsítja a folyamatot és kiküszöböli az emberi tényezőt a merge során.

Modern megközelítés — trunk-based development rövid élettartamú ágakkal. Ebben a munkafolyamatban a jóváhagyást órákon belül meg kell szerezni, különben a feladat elavultnak minősül és újraszinkronizálást igényel a main-nel. A magas review kultúrával rendelkező csapatok arra törekszenek, hogy a jóváhagyási idő ne haladja meg a 4 munkaórát.

Hibák a jóváhagyás során és hogyan kerüljük el ezeket

A leggyakoribb hiba — formális jóváhagyás a kód tényleges ellenőrzése nélkül. Amikor a PR nagy vagy a határidő közel van, a reviewr rányomhat az Approve-ra anélkül, hogy belemélyedne a változtatásokba. Ez leértéktelíti az egész code review folyamatot. Megoldás: állítson be korlátot a PR méretére (legfeljebb 400 sor), és használjon kódelemző eszközöket (SonarQube, CodeClimate) az automatikus ellenőrzéshez.

Második hiba — túlzottan szigorú jóváhagyás. Az ideális kód elvárása blokkolja a fejlesztést. A reviewrok néha stílisztikai észrevételek javítását követelik, amelyek nem befolyásolják a minőséget. Megoldás: egyértelműen válassza el a kötelező észrevételeket (blokkoló) és az opcionális javaslatokat (megjegyzések). A GitHub lehetővé teszi egyértelműen jelezni, hogy egy megjegyzés blokkoló-e.

Harmadik hiba — jóváhagyás CI/CD ellenőrzés nélkül. Még ha a kód helyesnek is tűnik, lehet, hogy nem fordul le vagy megbukik a teszteken. A beállított Branch Protection automatikusan blokkolja a merge-t piros CI esetén, de néhány csapat kikapcsolja ezt a védelmet a gyorsaság érdekében. Megoldás: mindig ellenőrizze a CI állapotát a jóváhagyás előtt, és soha ne hagyjon jóvá egy PR-t piros pipeline-nal.

• Formális jóváhagyás — a kód tényleges ellenőrzésének hiánya. Megoldás: 400 sor korlát PR-enként.
• Túlzott szigorúság — blokkolás stílisztikai észrevételek miatt. Megoldás: blocking és optional szétválasztása.
• CI figyelmen kívül hagyása — jóváhagyás piros pipeline-nal. Megoldás: mindig ellenőrizze az ellenőrzések állapotát.
• Szerző kijelölése — jóváhagyás a PR szerzőjétől. Megoldás: Branch Protection beállítása a szerző ellen.