4.4 Pull request folyamat

← 4. Git és verziókezelés a gyakorlatban

4.4 Pull request folyamat a valóságban

Áttekintő

A pull request (PR) – más rendszerekben merge request (MR) – az egyik legfontosabb kommunikációs eszköz egy fejlesztő csapatban. Sokan azt hiszik, hogy a PR csak egy technikai lépés: „nyomd meg a gombot, merge-elünk". A valóságban a PR egy párbeszéd. Benne van a változtatásod, a szándékod, a gondolkodásod – és a csapat visszajelzése.

Ez az alfejezet megmutatja, hogyan néz ki egy PR élete az elejétől a végéig: hogyan nyisd meg, mit írj bele, hogyan kezeld a review-t, és melyik merge stratégiát válaszd. Nem elvont elmélet – valódi munkahelyi szituációk.

Amit ebből a fejezetből tanulsz:

  • Mi a különbség draft PR és ready-for-review PR között
  • Miért számít a PR mérete, és hogyan tartsad kicsin
  • Hogyan kérd a review-t profi módon
  • Mit jelent a review kör és hogyan viselkedj benne
  • Merge commit, squash, rebase – melyiket mikor

Miért számít az állásinterjún?
Interjúkon rendszeresen rákérdeznek a PR folyamatra. „Hogyan szoktál PR-t csinálni?" – ez nem csak technikai kérdés, a csapatmunka érettségedet méri. Aki tudatos választ ad, kiemelkedik.

Miért számít production környezetben?
A PR az egyetlen pont, ahol a hibát még elkaphatják, mielőtt production-ba kerül. Egy jól csináld PR felgyorsítja a review-t, csökkenti a visszaküldések számát, és megmutatja, hogy professzionálisan gondolkodsz.

Részletes leírás

Mi az a pull request?

A PR egy kérelem: „kérem, húzzátok be a változtatásaimat a fő ágba." Ezt a kérést a csapat átnézi, visszajelzést ad, majd jóváhagyja vagy visszaküldi.

Különböző platformokon különböző a neve:

  • GitHub, Bitbucket: Pull Request (PR)
  • GitLab: Merge Request (MR)

A mechanizmus ugyanaz: feature branch → review → merge a célágba (általában main vagy develop).

Draft PR vs. Ready for Review

Draft PR (más neve: WIP – Work In Progress):

  • Jelzi: „dolgozom rajta, nem kész, ne reviewold még"
  • Korai visszajelzés kéréséhez ideális: „Ez az irány jó?"
  • Megakadályozza, hogy valaki véletlenül merge-elje
  • GitHub-on: Draft gombbal nyitod meg

Ready for Review:

  • Jelzi: „kész vagyok, kérem a review-t"
  • Ilyenkor már teszteltél, a kód lefut, ellenőrizted
  • GitHub-on: Convert to draft → Ready for review váltás lehetséges

Junior hiba: rögtön ready for review-ként nyitni meg, mielőtt az alap tesztelés megtörtént. A review körök drágák (időt vesznek el mindenkitől) – ne pazarold őket nyilvánvaló hibákra.

PR mérete – a kis PR vallás

A legtöbb tapasztalt csapatban van egy nem kimondott, de erősen érzett szabály: a kis PR jobb PR.

Miért?

  • Nagy PR (500+ sor) reviewolása 30-60 percet vesz el – senki nem szereti
  • Kis PR (50-150 sor) gyorsan átnézhető, hamarabb merge-elnek
  • Kisebb PR = kisebb hiba esélye = kevesebb visszaküldés
  • Ha van probléma, könnyebb visszaforgatni

Hogyan tartsad kicsin?

  • Egy PR = egy logikai változtatás (ne keverd a feature-t a refactorral)
  • Ha a feladat nagy, törd fel: először az alapozást, majd a feature-t
  • Ne rángasd be a nem kapcsolódó cleanup-okat (külön PR legyen)

Kivételek léteznek: néha egy feature elkerülhetetlenül nagyobb. Ilyenkor a PR leírásban magyarázd el a struktúrát, és kérd, hogy szakaszosan olvassák.

Hogyan kérd a review-t

Nem elég megnyitni a PR-t és várni. Profi módszer:

  1. Ellenőrizd a PR-t saját magad első körben

Nyisd meg a diff-et és olvasd végig, mintha te lennél a reviewer. Meglepő, hány nyilvánvaló hibát fogsz látni így.

  1. Töltsd ki a PR leírást (ld. 3.5-ös alfejezet részletesen)

Minimum: mit változtattál és miért, hogyan tesztelted, van-e mellékhatás.

  1. Assign reviewer-eket

A legtöbb csapatnál van konvenció: kinek kell reviewolnia. Ha nem tudod, kérdezd meg a teamleadet.

  1. Jelezd Slack-en / chat-ben

„PR kész, kérem a reviewt: [link]" – rövid, udvarias, konkrét. A GitHub értesítések elvesznek, a közvetlen jelzés nem.

  1. Add meg a prioritást/sürgősséget, ha releváns

„Blocker a deploy-hoz" vs. „ráér holnapig" – a reviewer tudja majd priorizálni.

A review kör folyamata

Egy PR ritkán megy át első körben változtatás nélkül. Különösen junioroknál. Ez normális.

Tipikus review kör:

PR megnyitás
    ↓
Reviewer(ek) átnézik
    ↓
Kommentek érkeznek
    ↓
Változtatások implementálása
    ↓
"Changes Requested" → "Resolved" vagy válasz
    ↓
Re-review
    ↓
Jóváhagyás (approve)
    ↓
Merge

Hogyan kezeld a kommenteket:

  • Minden kommentet nyugtázz: vagy fix-eled, vagy megmagyarázod, miért nem
  • Ne hagyj néma változtatásokat – írj vissza: „Javítva", „Átgondoltam, marad, mert…"
  • Ha nem értesz egyet: kérdezz, ne vitatkozz azonnal
  • Ha a komment nem egyértelmű: kérdezz rá, ne tippelj

Türelem: a review köröknél a visszacsatolás lassabb lehet, mint várnád. Ez nem azt jelenti, hogy senki nem törődik veled – a senioroknak is van saját munkájuk.

Merge stratégiák – melyiket mikor

Ez az a téma, ahol sok junior elvész. Három fő lehetőség van:

1. Merge commit (Create a merge commit)

main:    A --- B --- M
                      \
feature:         C --- D
  • A feature branch commitjei megtartódnak, plusz egy „merge commit" keletkezik
  • Előnye: teljes history megmarad, látszik mikor és mit merge-eltünk
  • Hátránya: a history „szőrös" lesz sok kis branchtől
  • Mikor: ha a csapat látni akarja a pontos branch-szerkezetet

2. Squash and merge

main:    A --- B --- S
  • A feature branch összes commitja össze van préselve egyetlen commitmá (S)
  • Előnye: tiszta, lineáris history; minden feature = egy commit a main-en
  • Hátránya: elvesznek az egyedi commitok (nem látszik a munka közbeni lépések)
  • Mikor: kisebb feature-ök, ahol a közbülső commitok nem fontosak; legtöbb startup/scaleup csapat ezt preferálja

3. Rebase and merge

main:    A --- B --- C' --- D'
  • A feature branch commitjei átíródnak, mintha mindig a legfrissebb main-ból indultak volna
  • Előnye: lineáris history, megmaradnak az egyedi commitok
  • Hátránya: history átírás (SHA-k megváltoznak), konfliktusok komplikáltabbak
  • Mikor: ha clean history kell és a csapat érti a rebase-t

Amit juniorként tudnod kell:
Kérdezd meg a csapatod, melyiket preferálják. Leggyakoribb válasz: squash and merge. Ne hozz egyedül döntést – a csapat konvencióját kövesd.

Mikor töröld a branch-et?

Merge után a feature branch felesleges. Általános szabály: merge után azonnal töröld.

  • GitHub-on: automatikus branch törlés beállítható (ajánlott)
  • Ha nem automatikus: a merge gomb alatt jelenik meg „Delete branch" opció
  • Miért fontos: a sok régi branch zsúfolttá teszi a repot és összezavar

Kivétel: hosszú élettartamú branch-ek (pl. release/1.2, hotfix/xyz) – ezeket csak akkor törlöd, ha az adott kiadás/javítás lezárult.

Életszerű példák

Példa 1: A junior, aki túl nagyot harapott

Ádám egy új feature-n dolgozik: felhasználói profil szerkesztése. Három napig kódol, aztán megnyit egy 800 soros PR-t: benne van a form, az API endpoint, az adatbázis migráció, egy nem kapcsolódó naming fix, és a CSS frissítések.

A senior reviewer visszaküldi: „Kérlek, bontsd szét. Először a migrációt, aztán az API-t, a UI legyen utolsó."

Mi ment rosszul? Ádám jó szándékkal csinálta – mindent egyszerre akart leszállítani. De a reviewer nem tud 800 sort alaposan átnézni, és ha bármi probléma van bármelyik részben, az egész review körülállhat.

Tanulság: tervezz PR-ban is. Mielőtt elkezdesz kódolni, gondold végig: hogyan törd fel kisebb szállítható egységekre?

Példa 2: A draft PR, ami gyorsan irányt mutat

Zsófia egy komplex refactoron dolgozik. Nem biztos benne, hogy a megközelítése jó. Ahelyett, hogy három napig kódolna bizonytalanul, megnyit egy draft PR-t 50 soros változtatással és ezt írja leírásba:

„Draft – nem kész. Az a kérdésem, hogy ez a service layer kiemelési megközelítés jó irány-e a csapatnak, mielőtt végigviszem az egész modulon."

A senior 10 perc alatt válaszol: „Igen, ez az irány, de a naming konvenciót változtasd meg."

Eredmény: Zsófia nem töltött három napot rossz irányban. Egy korai draft PR megmentett 2 nap munkát.

Példa 3: Merge stratégia döntés

Péter az első PR-ját nyitja meg. 8 commitmja van: „wip", „fix", „még egy fix", „remélem ez az", „végre", „cleanup", „cleanup 2", „kész".

A csapat squash and merge-et használ. A senior reviewer jóváhagyja a kódot, de megmutatja: „Nézd, squash-szel merge-elünk, így a commit historyd egy tiszta commit lesz a main-en. De legközelebb próbálj értelmes commit üzeneteket írni közbülső lépéseknél is – ha kell majd bisectolni, hasznos lesz."

Tanulság: a squash megment a csúnya historytól, de ez nem mentség az összes commit üzenetre. A folyamat közben írt commitok a saját munkádat dokumentálják.

Példa 4: A review kör kezelése

Anna kap 12 kommentet az első PR-jára. Az első reakciója: pánik.

Aztán végigolvassa őket. 8 db apró dolog (naming, kód stílus, hiányzó tesztek). 3 db kérdés (miért csináltad így?). 1 db blocker (biztonsági probléma az input validációban).

Anna priorizál: először a blockert javítja, majd a kis dolgokat. A kérdéses részeknél visszaír: „Azért csináltam így, mert X. Van-e jobb megközelítés?"

Eredmény: a második review körben már csak 2 komment van. Harmadik körben: approve.

Tanulság: a review kommentek nem személyes kritikák. Legyenek rendszerezve és priorizálva.

Feladatok és tesztek

Gyakorlati feladat: PR checklist összeállítása

Képzeld el, hogy az alábbi fiktív feladatot implementáltad: Felhasználói profilképek feltöltése – egy új form endpoint, ami képfájlt fogad, validálja és elmenti a szerverre.

Az implementáció kész. Mielőtt megnyitod a PR-t, menj végig az alábbi checklistán és jelöld meg, mi teljesül és mi nem – majd írj egy mondatos PR leírást!

PR megnyitás előtti checklist:

  • [ ] A kód lefut lokálisan
  • [ ] Az új funkcionalitás tesztelve van kézzel
  • [ ] Nincsenek console.log / print / var_dump maradékok
  • [ ] A változtatás illeszkedik a csapat kódstílusához
  • [ ] A PR leírásban megmagyarázom, miért változtattam
  • [ ] A PR leírásban leírom, hogyan teszteltem
  • [ ] Jelzem, ha van mellékhatás vagy kockázat
  • [ ] A PR mérete ésszerű (nem 800 sor egyszerre)
  • [ ] Az assignált reviewer-ek megvan
  • [ ] Értesítettem a reviewert chat-en is

Tesztkérdések

1. kérdés
Mikor érdemes Draft PR-t megnyitni?

a) Soha – csak kész kódhoz nyiss PR-t
b) Amikor korai visszajelzést szeretnél az irányra, de a kód még nem kész
c) Amikor elfelejtettél valamit és nem akarsz új branchet
d) Csak akkor, ha a CI/CD pipeline piros

Helyes válasz: b

2. kérdés
Miért jobb a kis PR a nagyobb PR-nál? (Több válasz is helyes lehet)

a) Gyorsabban reviewolható
b) Kisebb a hibakockázat
c) Könnyebb visszaforgatni, ha probléma van
d) Több commitot tartalmaz
e) A reviewer kevesebbet dolgozik összesen

Helyes válaszok: a, b, c

3. kérdés
Mi a squash and merge lényege?

a) Az összes commit átíródik, mintha mindig a legfrissebb main-ből indultak volna
b) A feature branch összes commitja egyetlen commitmá préselődik össze a main-en
c) A branch history teljes mértékben megmarad, plusz egy merge commit keletkezik
d) A branch commitjei törlődnek merge után

Helyes válasz: b

4. kérdés
Kapsz 10 review kommentet. Az egyik blocker (biztonsági probléma), a többi stílus és naming. Mi az első lépés?

a) Kezdd a naming javításokkal, azok a legegyszerűbbek
b) Először a blockert javítsd, utána a kisebb dolgokat
c) Válaszolj minden kommentre, de ne változtass semmit amíg az egészet át nem olvastad
d) Kérdezd meg a reviewert, hogy szükséges-e az összes javítás

Helyes válasz: b

5. kérdés
Mikor töröld a feature branch-et?

a) Soha – a branch-ek fontosak a history szempontjából
b) Egy héttel merge után
c) Közvetlenül merge után
d) Csak akkor, ha a csapat vezető utasítja

Helyes válasz: c

6. kérdés
A csapatod squash and merge stratégiát használ. Te rebase and merge-szel merge-elsz egy PR-t véletlenül. Mi a következmény?

a) Semmi – minden merge stratégia ugyanolyan eredményt ad
b) A commit history eltér a csapat konvenciójától, a main history „piszkosabb" lesz
c) A branch automatikusan törlődik
d) A CI/CD pipeline megáll

Helyes válasz: b

7. kérdés
Nyitottál egy PR-t. Kinek szólsz, hogy reviewolják?

a) Nem kell szólni senkinek – a GitHub értesítés elég
b) Assign reviewer-eket a PR-ban, és jelezd chat-en is (Slack/Teams/stb.)
c) Csak akkor szólj, ha 24 óra után sem érkezik review
d) E-mailben értesítsd a teamet

Helyes válasz: b

8. kérdés
Melyik merge stratégia tartja meg legtisztábban a lineáris main history-t, miközben az egyedi feature commitok is megmaradnak?

a) Merge commit
b) Squash and merge
c) Rebase and merge
d) Fast-forward merge

Helyes válasz: c

9. kérdés
Ádám egy PR-ban belecsúsztat egy nem kapcsolódó cleanup-ot (régi unused változók törlése) a feature mellé. Miért problémás ez?

a) Nem problémás – a cleanup jobb kódot eredményez
b) Nehezebb a review, összekeverednek a logikai változtatások, és ha vissza kell forgatni, mindkét dolog elvész
c) A cleanup commitok nem kerülhetnek PR-ba
d) Mert a CI/CD nem tudja kezelni

Helyes válasz: b

10. kérdés
A PR leírásodban mi az abszolút minimum, amit érdemes megírni?

a) Semmi – a kód magáért beszél
b) Csak a ticket száma
c) Mit változtattál és miért, valamint hogyan tesztelted
d) Az összes módosított fájl listája

Helyes válasz: c

Scroll to Top