5. témakör · Csapatmunka GitHubon · 24. fejezet
Megvan minden eszköz: ág, pull request, review, issue. Egy csapatnak viszont közös szabály is kell arra, hogyan kerül egy változás a közös
main-re. A legegyszerűbb és legelterjedtebb ilyen szabályrendszer a GitHub Flow. Ebben a fejezetben megismered a lépéseit,
a csapatszabályokat, és beállítod a védett main ágat, amely a szabályokat ki is kényszeríti.
A munkafolyamat (workflow, branching strategy) a csapat megállapodása arról, milyen ágakat használtok, hogyan kerül a munka a közös ágra, és ki dönt a beolvasztásról. A Git ezt nem írja elő: ugyanazokkal a parancsokkal sokféle munkafolyamat megvalósítható.
A GitHub Flow alapgondolata egyetlen mondat: a main mindig működőképes (kiadható), minden más munka rövid életű ágakon folyik, és pull requesten keresztül kerül a main-re.
git switch -c feature/galeriagit commit -m "feat: …"git push -u origin …git push (javítás)Squash and mergegit pull · git branch -dmain. Minden más ág napokig, legfeljebb néhány hétig él.Kattints a lépésekre a helyes sorrendben! Egy új funkció útja a gépedtől a kiadott main-ig.
Tipp: a hiba nem büntet, csak számolja a kirakó.
A GitHub Flow keret; a részleteket a csapat maga dönti el, és jó, ha le is írja (CONTRIBUTING.md). Egy iskolai projektcsapat szabálylistája így nézhet ki:
main-re senki nem push-ol közvetlenül: minden változás PR-ban jön (a védett ág ki is kényszeríti).feature/…, fix/…, docs/…, kisbetűvel, kötőjellel (feature/kapcsolat-oldal).feat:, fix:, docs:), 7. fejezet.Closes #…, ha issue-hoz tartozik.git switch main, git pull; új munka mindig a friss main-ből.Szabályos ez a GitHub Flow (és a fenti csapatszabályok) szerint?
A szabály annyit ér, amennyit betartanak. A védett ág (branch protection rule) a GitHubon kényszeríti ki: a repó Settings → Branches → Add branch protection rule
oldalán a Branch name pattern legyen main, és kapcsold be a kívánt szabályokat.
| Beállítás | Hatása |
|---|---|
| Require a pull request before merging | a main-re csak PR-on keresztül kerülhet változás; a közvetlen push elutasítódik |
| ↳ Required approvals: 1 | legalább egy jóváhagyás kell a merge-hez (a saját nem számít) |
| ↳ Dismiss stale pull request approvals… | új commit után a korábbi jóváhagyás elavul (21. fejezet) |
| Require status checks to pass | csak zöld automatikus ellenőrzés (CI) mellett lehet beolvasztani (27. fejezet) |
| ↳ Require branches to be up to date | a PR ágának tartalmaznia kell a main legfrissebb állapotát (Update branch) |
| Require conversation resolution | minden megjegyzésszálat le kell zárni (Resolve conversation) |
| Allow force pushes (alapból ki) | kikapcsolva a main történetét senki nem írhatja át |
| Allow deletions (alapból ki) | kikapcsolva a main nem törölhető |
Ha valaki mégis közvetlenül push-ol a védett main-re, ezt kapja:
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote:
remote: - Changes must be made through a pull request.
To https://github.com/anna-kovacs/osztalyoldal.git
! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/anna-kovacs/osztalyoldal.git'
Az újabb GitHub-felületen a Settings → Rules → Rulesets ugyanezt tudja, rugalmasabban (több ágra, címkékre, kivételekkel). A fogalmak ugyanazok; a klasszikus branch protection rule továbbra is működik. Privát repóban a védett ágakhoz fizetős csomag kellhet, nyilvános repóban ingyenes.
Gyakori hiba: elfelejtesz ágat nyitni, a main-en commitolsz, és a push-t elutasítja a védelem. Semmi gond, a commitot átteszed egy ágra (10. és 11. fejezet):
PS> git branch docs/keszitok # új ág a mostani commitra (a munka megmarad rajta) PS> git reset --hard origin/main # a helyi main vissza a GitHub-os állapotra PS> git switch docs/keszitok PS> git push -u origin docs/keszitok # és innen már PR
A sorrend fontos: a git branch „megjelöli” a commitot, így a reset --hard után sem vész el. Fordított sorrendben csak a reflogból
tudnád visszahozni (10. fejezet). Nem commitolt változásnál egyszerűbb: git switch -c docs/keszitok — a módosítások átjönnek az új ágra.
| GitHub Flow | Git Flow | Trunk-based | |
|---|---|---|---|
| Hosszú életű ágak | main | main + develop | main (trunk) |
| Rövid életű ágak | feature/fix ágak, PR-ral | feature/, release/, hotfix/ ágak | nagyon rövidek (órák), vagy közvetlen commit |
| Kiadás | a main bármikor kiadható | tervezett verziók release ágakon | folyamatos, gyakran naponta többször |
| Kinek való? | webes projektek, kis és közepes csapatok, iskolai projektek | verziózott termékek (pl. telepíthető program több támogatott verzióval) | tapasztalt csapat, erős automatikus teszteléssel |
Kezdőknek és iskolai csapatoknak a GitHub Flow a legjobb választás: kevés szabály, és minden eleme (ág, PR, review, védett main) a GitHub felületén is látszik.
Az osztalyoldal repó a tiéd, Péter a csapattársad. Kapcsold be a védelmet, nézd meg, mit szól a GitHub, ha mégis közvetlenül push-olsz,
aztán vidd végig a változást szabályosan.
⭐ alap · ⭐⭐ haladó · ⭐⭐⭐ kihívás
Egy saját nyilvános repódban állíts be védett main ágat (kötelező PR, 1 jóváhagyás). Próbálj közvetlenül a weben szerkeszteni a main-en: mit ajánl fel a GitHub?
Commitolj a gépeden a védett main-re, és próbáld feltölteni. Olvasd el a GH006 üzenetet, majd mentsd a commitot egy ágra a fejezet módszerével.
Írjátok meg a csapatotok CONTRIBUTING.md fájlját a 4. szakasz mintájára (ágnevek, commitüzenet, PR-méret, review, merge-mód), és tegyétek fel PR-ral.
Párban vigyetek végig egy teljes GitHub Flow kört: issue → ág → commitok → draft PR → review → javítás → jóváhagyás → squash merge → ág törlése → git pull.
Kapcsold be a Require branches to be up to date és a Require conversation resolution szabályt. Idézz elő olyan helyzetet, amikor emiatt nem lehet beolvasztani, és oldd meg.
Hasonlítsd össze egy mondatban a GitHub Flow-t és a Git Flow-t: melyik illik egy iskolai weboldal-projekthez, és melyik egy telepíthető programhoz, amelynek több verzióját támogatni kell?
Egy héten át dolgozzatok csapatban szigorú GitHub Flow szerint (védett main, Projects tábla, issue minden feladathoz). A hét végén a Pulse és az Insights oldal alapján értékeljétek: hány PR készült, mennyi idő alatt olvadtak be?
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.
| Fogalom | Jelentés |
|---|---|
| munkafolyamat (workflow) | a csapat megállapodása az ágak használatáról és a változások útjáról |
| GitHub Flow | egy hosszú életű ág (main, mindig kiadható) + rövid életű ágak, PR-ral, review-val |
| feature branch | rövid életű ág egy funkcióhoz vagy javításhoz |
| védett ág (branch protection rule) | GitHub-szabály egy ágra: kötelező PR, jóváhagyás, ellenőrzések, tiltott force push és törlés |
| GH006 | a GitHub hibaüzenete, ha egy push megsérti a védett ág szabályait |
| status check | automatikus ellenőrzés (pl. teszt), amelynek zöldnek kell lennie a merge-hez |
| Git Flow | összetettebb munkafolyamat develop, release és hotfix ágakkal |
| trunk-based development | mindenki nagyon gyakran, nagyon kis lépésekben olvaszt a fő ágba |
| CONTRIBUTING.md | a csapat (projekt) hozzájárulási szabályai |
git pull.CONTRIBUTING.md-be.git branch új-ág → git reset --hard origin/main → az új ágról PR.Ezzel a csapatmunka témakör végére értél. A következő témakörben az eszközöké a főszerep: jön a Git a VS Code-ban és a Visual Studióban.