Vezérlőpult
21. Kódáttekintés · Csapatmunka GitHubon

5. témakör · Csapatmunka GitHubon · 21. fejezet

Kódáttekintés (code review)

A pull request igazi értéke az átnézés: valaki más is elolvassa a változást, mielőtt a közös ágra kerül. Ebben a fejezetben megtanulod, hogyan kérj és hogyan adj jó review-t a GitHubon: soros megjegyzés, javasolt módosítás, jóváhagyás, változtatáskérés. És azt is, hogyan írj olyan megjegyzést, aminek a társad örül, nem pedig megsértődik rajta.

WebKód-bíróHangnem-besorolóReview-labor16 kvízkérdés

Tanulási célok

1Miért nézzük át egymás kódját?

🐞 Hibák koránAmit a bíráló a PR-ban észrevesz, az nem jut el a felhasználókig. Minél korábban derül ki egy hiba, annál olcsóbb javítani.
📖 ÉrthetőségHa a bíráló nem érti a kódot, fél év múlva a szerző sem fogja. A review kikényszeríti a jó neveket és a tiszta szerkezetet.
🤝 TudásmegosztásÍgy nem csak egy ember ismeri a projekt egy részét. Ha ő beteg, más is tud hozzányúlni.
🎓 TanulásMindkét irányban: a bíráló új megoldásokat lát, a szerző tippeket kap.
ℹ️ A KÓDOT NÉZZÜK, NEM AZ EMBERT

A review nem vizsga és nem ítélet. A cél a közös munka minősége: a bíráló segít, a szerző pedig nem védekezik, hanem örül, hogy más is ránézett. A jó csapatban mindenki kap megjegyzést, a legtapasztaltabb fejlesztő is.

2Review kérése

# .github/CODEOWNERS — minden sor: minta, majd a felelős(ök)
*.css         @szabo-lili
/docs/        @toth-peter
*             @anna-kovacs
A PR-listábanJelentése
Review requiredmég senki nem hagyta jóvá (és a szabály szerint kell)
Approvedlegalább egy bíráló jóváhagyta
Changes requestedegy bíráló változtatást kért, és ez még áll

3Az átnézés menete

  1. Olvasd el a leírást. Mit akar a PR, miért, és hogyan ellenőrizhető? Ha ez nem derül ki, az már az első megjegyzés.
  2. Files changed: menj végig fájlonként. A kész fájlokat a Viewed jelölővel pipálhatod ki.
  3. Megjegyzés egy sorhoz: vidd az egeret a sor fölé, és kattints a kék + jelre. Több sorhoz: húzd a + jelet, vagy Shift + kattintás.
  4. Gyűjtés: a Start a review gombbal a megjegyzés még Pending, csak te látod. Így a társad nem kap tíz külön értesítést, hanem egyetlen, összefüggő review-t. (Az Add single comment azonnal elküldi a megjegyzést — egy gyors kérdéshez jó.)
  5. Review changes: a jobb felső zöld gombbal írsz egy rövid összegzést, kiválasztod a döntést, és Submit review.

Egy webes felületű változást (HTML, CSS, JavaScript) érdemes ki is próbálni. Hozd le a PR ágát a gépedre:

PS> git fetch
PS> git switch feature/kapcsolat
branch 'feature/kapcsolat' set up to track 'origin/feature/kapcsolat'.
Switched to a new branch 'feature/kapcsolat'
PS> start kapcsolat.html          # megnyitás a böngészőben

A GitHub Desktopban ugyanez: Current branch → Pull requests fül → kattints a PR-ra. Ha a szerző később javít, a gépeden git pull hozza le.

4Javasolt módosítás (suggestion)

Ha pontosan tudod, mi lenne a jó sor, ne csak írd le, hanem javasold. A megjegyzés szerkesztőjében a ± gomb (Add a suggestion) beszúr egy különleges kódblokkot a sor jelenlegi tartalmával; ezt írod át:

A címben elírás van.
```suggestion
<h1>Kapcsolat</h1>
```
Suggested change
- <h1>Kapcsolt</h1>
+ <h1>Kapcsolat</h1>
Commit suggestionAdd suggestion to batch

5A három döntés

💬 CommentÁltalános visszajelzés, döntés nélkül. Kérdésekhez, ötletekhez, ha még nem néztél át mindent.
✅ Approve„Szerintem mehet.” Védett ágon (24. fejezet) ennyi jóváhagyás kell a merge-hez.
✋ Request changes„Ezt javítani kell, mielőtt beolvad.” Védett ágon amíg ez áll, a merge tiltott.

6A szerző oldala: válasz a review-ra

  1. Minden megjegyzésre reagálj: vagy javítod, vagy válaszolsz (ha nem értesz egyet, indokold; a vita a kódról szól).
  2. Javítás: új commit ugyanarra az ágra, majd git push. A PR frissül, a régi sorokra írt megjegyzések Outdated jelzést kapnak.
  3. Resolve conversation: a megoldott szálat összecsukod, így látszik, mi van még hátra.
  4. Re-request review (↻ a bíráló neve mellett): jelzed, hogy kész vagy, nézze át újra.
⚠️ ÚJ COMMIT ELAVULTTÁ TEHETI A JÓVÁHAGYÁST

Ha a védett ág szabályában be van kapcsolva a Dismiss stale pull request approvals when new commits are pushed, egy jóváhagyás után feltöltött új commit érvényteleníti a korábbi Approve-ot: újra át kell nézni. Így nem lehet egy jóváhagyott PR-ba utólag „becsempészni” valamit.

💡 REVIEW KÖZBEN NE ÍRD ÁT A TÖRTÉNETET

Átnézés alatt inkább új commitokat tegyél fel, ne amend + force push-t: így a bíráló látja, mi változott az előző átnézés óta. A „javítás” commitok sokasága miatt ne aggódj: a merge-nél a Squash and merge egyetlen committá gyúrja őket (20. fejezet).

7Mire figyelj átnézéskor?

⛔ JELSZÓ VAGY KULCS A PR-BAN

Ne érd be egy Request changes-szel: a titok már feltöltődött, a Git története megőrzi, és egy nyilvános repóban percek alatt megtalálják. Szólj a szerzőnek, hogy a jelszót, kulcsot azonnal cserélje le (érvénytelenítse), és csak utána javítsa a kódot (a titok helye: környezeti változó, .env a .gitignore-ban, 9. fejezet).

8Jó megjegyzés, rossz megjegyzés

A jó megjegyzés konkrét (hol, mi a gond), indokolt (miért), segítő (javasol megoldást) és kedves (a kódról szól, nem a szerzőről). A dicséret is megjegyzés: írd le, ha valami tetszik!

Helyett……inkább
„Ez rossz.”„A 12. sorban a link index.htm-re mutat, de a fájl index.html, ezért 404-et kapunk.”
„Miért csináltad így??”„Kérdés: miért lett külön fájlban a lábléc? Ha minden oldalon ugyanaz, esetleg közös részként is betölthetnénk.”
„Nem tetszik a szín.”„Javaslat (nem blokkoló): a gomb színe lehetne a --accent változó, így egységes a többi gombbal.”
„Te mindig elírod.”„Apróság: elírás a címben (Kapcsolt → Kapcsolat), javaslatot tettem.”
—„Ügyes, ez a táblázat sokkal olvashatóbb, mint a régi lista! 👍”

Sok csapat előtaggal jelzi a megjegyzés súlyát:

ElőtagJelentése
nit: / apróság:kicsiség (pl. szóköz, elírás), nem akadálya a merge-nek
kérdés:nem értem, magyarázd el (lehet, hogy minden rendben van)
javaslat:ötlet, a szerző dönt róla
blokkoló:ezt javítani kell a merge előtt

Milyen ez a megjegyzés?

Döntsd el a review-megjegyzésről, hogy jó-e, vagy mi a baj vele.

1 / 9Pontszám: 0
…

9Kód-bíró

Lili PR-t nyitott: feat: órarend oldal. Te vagy a bíráló. A változásban négy hiba bújik meg. Kattints azokra a sorokra, amelyekhez megjegyzést írnál, majd ellenőrizd, és döntsd el, milyen review-t küldesz!

Kód-bíró: feat: órarend oldal #14

Megjelölt sorok: 0

10Review-labor

Péter pull requestet nyitott az osztalyoldal repóban (feat: kapcsolat oldal), és tőled kért átnézést. Nézd át a GitHubon, próbáld ki a gépeden, javasolj, dönts — és ha minden rendben, olvaszd be.

PowerShell + Git + GitHub

Windows PowerShell
Küldetések 0 / 8

    11Feladatok

    Gyakorló feladatok

    ⭐ alap · ⭐⭐ haladó · ⭐⭐⭐ kihívás

    21.1⭐Web

    Párban: nyissatok egy-egy PR-t, és kérjétek meg egymást bírálónak. Mindketten írjatok legalább egy soros megjegyzést és egy dicséretet, majd hagyjátok jóvá a másik PR-ját.

    21.2⭐Web

    A társad PR-jában javasolj egy javítást suggestion blokkal. A szerző fogadja el a Commit suggestion gombbal. Keressétek meg a commitban a Co-authored-by sort.

    21.3⭐

    Írd át a Hangnem-besoroló „túl általános” és „bántó” megjegyzéseit jó megjegyzéssé (konkrét, indokolt, segítő, kedves).

    21.4⭐⭐CLI

    Egy társ PR-jának ágát hozd le a gépedre (git fetch, git switch …), próbáld ki, és a tapasztalatodat írd le a review összegzésében.

    21.5⭐⭐Web

    Használd a Start a review módot: gyűjts össze legalább három megjegyzést, és egyetlen review-ként küldd be Request changes döntéssel. A szerző javítson, válaszoljon, oldja fel a szálakat, és kérjen újra átnézést; te pedig hagyd jóvá.

    21.6⭐⭐Web

    Készíts .github/CODEOWNERS fájlt, amely a *.css fájlokhoz automatikusan egy társadat kéri bírálónak. Próbáld ki egy CSS-t módosító PR-ral.

    21.7⭐⭐⭐

    Írjatok a csapatnak review-szabályzatot (mit nézünk, hány jóváhagyás kell, milyen előtagokat használunk, mennyi időn belül válaszolunk), és tegyétek a repóba CONTRIBUTING.md néven.

    12Önellenőrző kvíz

    Ellenőrizd magad!

    Az egyválasztós kérdéseknél kattints a válaszra. A többválasztósaknál jelöld be az összes helyeset, majd nyomd meg az Ellenőrzés gombot.

    13Fogalomtár

    FogalomJelentés
    code review (kódáttekintés)a változás átnézése egy másik fejlesztő által, mielőtt a közös ágra kerül
    reviewer (bíráló)akitől átnézést kértek, vagy aki átnézte a PR-t
    soros megjegyzésa Files changed fülön egy vagy több sorhoz írt megjegyzés
    Start a review / Pendinga megjegyzések gyűjtése; beküldésig csak a bíráló látja őket
    suggestion (javasolt módosítás)```suggestion blokk, amelyet a szerző egy kattintással commitolhat
    Comment / Approve / Request changesa review három döntése: visszajelzés / jóváhagyás / változtatáskérés
    Resolve conversationegy megjegyzésszál megoldottként való lezárása
    Re-request reviewújabb átnézés kérése a javítások után
    stale approvalelavult jóváhagyás: új commit után (ha a szabály kéri) már nem számít
    CODEOWNERSfájl, amely megadja, mely fájlokhoz ki a felelős bíráló
    nit / LGTMapróság, nem blokkoló megjegyzés / „looks good to me”, jóváhagyó rövidítés

    14Összegzés

    1. A review célja a minőség és a tudásmegosztás: a kódot nézzük, nem az embert.
    2. Átnézés: leírás → Files changed → soros megjegyzések (Start a review) → Review changes → döntés; webes változást a gépeden is próbálj ki.
    3. Egyértelmű apró javításhoz ```suggestion: a szerző egy kattintással elfogadja, te társszerző leszel.
    4. Comment: visszajelzés; Approve: mehet; Request changes: javítani kell. Saját PR-t nem lehet jóváhagyni.
    5. Szerzőként: javítás ugyanarra az ágra, válasz, Resolve conversation, Re-request review. Titok a PR-ban: azonnali csere.

    A következő fejezetben olyan repóhoz járulsz hozzá, amelyhez nincs írási jogod: jön a fork.