Pull Request: mi ez, létrehozási folyamat és code review

Mi az a Pull Request?

Pull Request (PR) — egy formális kérés a változtatások egyik ágból a másikba történő befoglalására egy elosztott verziókezelő rendszer keretein belül. A PR a kollaboratív fejlesztés központi eleme a GitHub, GitLab és Bitbucket platformokon, ötvözve a kód megbeszélését, az automatikus tesztelést és a változtatások jóváhagyási folyamatát.

A „Pull Request” elnevezés tükrözi a művelet lényegét: a fejlesztő kéri (request) a tároló tulajdonosát, hogy „húzza be” (pull) a változtatásait. A kifejezést a GitHub vezette be 2008-ban — ezelőtt hasonló mechanizmus létezett patch-ek és merge request (GitLab kifejezés) formájában. Manapság a PR de facto szabvány a csapatmunkához a Git-ben.

A GitHub Octoverse, 2025 szerint a nyílt forráskódú projektek 89%-a megköveteli a PR létrehozását a változtatásokhoz. Vállalati fejlesztésben ez az arány eléri a 95%-ot. A PR nemcsak technikai eszközzé, hanem a fejlesztési kultúra részévé is vált: a PR-en keresztül történik a tudásátadás, a hibák észleése és az architekturális döntések összehangolása.

A Pull Request összetevői

Egy tipikus PR címből, leírásból, a módosított fájlok listájából (diff), a reviewerek észrevételeiből és az CI-ellenőrzések állapotából áll. Minden PR egy adott forrás és célághoz van kötve, és az egyesítés után automatikusan törölhető.

Hogyan kell Pull Request-et létrehozni

PR létrehozása a feature ág távoli tárolóban történő közzétételével kezdődik. A push után a fejlesztő megnyitja a PR-t a platform interfészén vagy CLI-n (gh, glab) keresztül. Nézzük meg a folyamatot a GitHub példáján.

Ág push-olása és PR megnyitása

Első lépés — push-olja a feature ágat a távoli tárolóba, és hozzon létre Pull Request-et a webes interfészen vagy parancssoron keresztül.

# Hozza létre és push-olja a feature ágat
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Hozzon létre PR-t GitHub CLI-n keresztül
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

A PR létrehozása után a GitHub automatikusan elindítja a CI-csővezetékeket (GitHub Actions), ellenőrzi az összeütközéseket a célággal, és meghívja a reviewereket. A PR leírás sablonja a .github/PULL_REQUEST_TEMPLATE.md fájlon keresztül konfigurálható, hogy minden PR tartalmazza a kötelező szekciókat: cél, változtatások, tesztelés, kapcsolódó feladatok.

Leírás és címkézés

Minőségi PR leírás tartalmazza: a feladatra mutató linket (issue/ticket), a változtatások rövid leírását, tesztelési útmutatót és a kapcsolódó változtatások listáját. A címkék (bug, feature, refactoring) segítenek kategorizálni a PR-eket, az assignee-k és reviewerek pedig automatikusan kerülnek kijelölésre a CODEOWNERS-en keresztül.

# Rendeljen reviewereket a CODEOWNERS-en keresztül (fájl a tároló gyökerében)
# Példa .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Hozzon létre PR-t reviewer kijelöléssel gh cli-n keresztül
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — a GitHub/GitLab szabványos mechanizmusa a reviewerek automatikus kijelölésére a módosított fájlok alapján. Például bármilyen változtatás az src/auth/ könyvtárban automatikusan kijelöli a team-auth és senior-dev tagokat reviewerként. Ez felgyorsítja a folyamatot és garantálja, hogy a megfelelő emberek látják a PR-t.

PR frissítése review után

A reviewer észrevételeinek kézhez vétele után a fejlesztő javításokat végez ugyanabban a feature ágban és új commit-okat push-ol — a PR automatikusan frissül. Fontos, hogy ne írja felül a történelmet (rebase) a közzétett feature ágban, ha a PR már nyitva van, mert ez megszakítja a kapcsolatot a konkrét commit-okhoz az észrevételekben.

# Végezze el a változtatásokat a reviewer észrevételei szerint
git checkout feature/biometric-auth
# javítsa a kódot
git commit -m "fix: handle biometric timeout per review"
git push

# A PR automatikusan frissülni fog
# Jóváhagyás után — egyesítse a PR-t a GitHub interfészén keresztül

A code review folyamata

Code review — a Pull Request központi eleme. A reviewer ellenőrzi a változtatásokat helyesség, kódstílus, biztonság és architekturális összhang szempontjából. A minőségi review nemcsak megelőzi a hibákat, hanem terjeszti a kódbázis ismeretét a csapaton belül.

A Google Engineering Practices (2025) a következő code review alapelveket ajánlja: a reviewer értse meg a változtatások kontextusát, adjon konkrét ajánlásokat általános észrevételek helyett, válassza el a technikai és stilisztikai észrevételeket. A review ideje ne haladja meg a 24 órát a PR létrehozásától számítva.

Mobilalkalmazás-fejlesztéshez a code review speciális ellenőrzéseket tartalmaz: kompatibilitás a targetSdk-val, a lifecycle (Android) / view lifecycle (iOS) helyes kezelése, memóriaszivárgások hiánya (LeakCanary, Instruments), sötét téma és lokalizáció támogatása. Ezek az ellenőrzések automatizálhatók linterekkel és Detekt/ktlint-tel.

Az észrevételek típusai

A PR platformok három típusú észrevételt támogatnak: általános (az egész PR-hez), soron belülit (egy adott kódsorhoz) és javaslatokat (suggestions cserekóddal). A javaslatok lehetővé teszik a változtatás egy kattintással történő alkalmazását, ami felgyorsítja a folyamatot és csökkenti az iterációk számát.

Miután az összes észrevétel megoldásra került és a CI-ellenőrzések sikeresek, a reviewer jóváhagyást (Approved) küld. A PR egyesíthető. A GitHub és GitLab támogatja az ágvédelmi szabályokat (branch protection rules): kötelező jóváhagyások száma, kötelező CI-ellenőrzések, push tiltása a main-be PR nélkül. Mobil projektek esetén az ágvédelem tartalmazza a build-ellenőrzést is: a PR nem egyesíthető, ha az alkalmazás nem épül fel (gradle build failed / xcodebuild failed).

Konfliktusok feloldása a PR-ben

Merge-konfliktusok a Pull Request-ben normális helyzet aktív csapatmunka esetén. A platformok konfliktusmegoldást kínálnak webes interfészen keresztül (egyszerű konfliktusokhoz) vagy helyi megoldást javasolnak. A GitHub Actions automatikusan ellenőrzi az egyesíthetőséget minden push-nál a feature ágba, és konfliktusként jelöli meg a PR-t, ha az egyesítés nem lehetséges.

Pull Request bevált gyakorlatai

A hatékony Pull Request-ek felgyorsítják a code review-t és csökkentik a hibák számát. A SmartBear (2025) kutatása kimutatta, hogy a 200 kódsorig terjedő PR-ek kétszer több érdemi észrevételt kapnak, mint az 1000 sornál nagyobb PR-ek, és a review ideje háromszor rövidebb.

• Kis PR-ek — optimális méret 100-300 sor. A nagy PR-eket ossza logikai részekre: minden PR egy feladatot old meg. Ez leegyszerűsíti a review-t és csökkenti a konfliktusok valószínűségét
• Érthető leírás — cím a Conventional Commits szerint (feat:, fix:, refactor:), a PR tartalma tartalmazza a „mit és miért”, nem a „hogyan” (a kód magáért beszél). Sablon: cél → változtatások → tesztelés → kapcsolódó problémák
• Gyors visszajelzés — review 24 órán belül. Ha a PR több mint egy napot vár — a csapat elveszti a kontextust, nő a konfliktusok száma a merge-nél
• Automatizálás — a linterek, formatterek és tesztek automatikusan induljanak a PR létrehozásakor. Ne engedje a PR egyesítését piros CI-ellenőrzésekkel
• Draft PR — használja az architektúra korai megbeszéléséhez. A Draft PR nem igényel review-t és nem egyesíthető, de lehetővé teszi a kód korai fázisban történő megjelenítését a kollégáknak

További gyakorlatok: ne hozzon létre PR-t péntek este (senki sem fog review-zni hétfőig), kérjen review-t 1-2 embertől (több lassítja a folyamatot a minőség növelése nélkül), használjon squash merge-t a történelem tömörítéséhez az egyesítés előtt. Mobil projektekhez ajánlott a PR leírásában linket adni a teszt build-hez (Firebase App Distribution / TestFlight), hogy a reviewer ellenőrizhesse a változtatásokat egy működő alkalmazásban.

Pull Request különböző platformokon

A PR-rel való munkához a fő platformok a GitHub, GitLab és Bitbucket. A közös koncepció ellenére mindegyiknek vannak olyan jellemzői, amelyeket figyelembe kell venni a csapat számára történő eszközválasztáskor.

GitHub — a legnépszerűbb platform a legnagyobb közösséggel, Actions-szel a CI/CD-hez és kiterjedt alkalmazás ökoszisztémával (GitHub Marketplace). GitLab a beépített CI/CD-vel és a teljes self-hosted telepítés lehetőségével tűnik ki. Bitbucket szorosan integrálódik a Jira és Atlassian ökoszisztémába, népszerű vállalati környezetben.

Mobilalkalmazás-fejlesztéshez a platform választását gyakran a CI/CD képességek határozzák meg: a GitHub Actions támogatja a macOS futtatókat iOS építéséhez, a GitLab beépített futtatókkal rendelkezik iOS/Android rendszerhez, a Bitbucket jól integrálódik a Firebase Test Lab-lel. A platformtól függetlenül a PR folyamata ugyanaz marad: ág → review → CI → merge.